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Preface 


This  report  provides  the  results  of  a  concept-formulation  project  that  examines 
the  Army's  needs  to  conduct  command  and  control  on  the  move  (C^TM)  and 
some  of  the  ways  of  satisfying  those  needs.  As  a  concept  formulation  study,  it 
intentionally  lacks  a  rigorous  examination  of  system  complexities,  of  their 
capabilities  and  performance,  and  of  their  cost  tradeoffs.  However,  the  study 
does  identify  informational  and  physical  categories  that  can  be  used  to  evaluate 
C4  architectures  qualitatively,  and  later  quantitatively,  and  it  provides 
suggestions  for  ways  to  make  comparisons  between  them.  Study  results  were 
briefed  at  TRADOC,  Ft.  Monroe,  the  Battle  Command  Battle  Lab,  Ft. 
Leavenworth,  and  at  the  Signal  School  and  Center,  Ft.  Gordon. 

The  report  serves  to  document  a  concept-formulation  study  effort  begun  in  1992 
with  tasking  from  TRADOC  directed  at  the  C^TM  vehicle  operations  and 
command  post  restructuring.  Initial  findings  showed  the  importance  of  the 
operational  C2  system  to  any  success  for  C^TM  vehicles  on  the  battlefield  and 
improvement  of  command  post  operations.  From  these  findings  and  broader 
tasking  from  the  Deputy  Chief  of  Staff  for  Operations  and  Plans  and  the  Deputy 
Chief  of  Staff  for  Intelligence,  the  emphasis  on  analysis  of  the  operational  C2 
systems  begun  in  this  paper  was  continued.  Results  of  follow-on  efforts  have 
been  described  in  related  work  in  progress  by  Pat  Allen  and  Ed  Cesar  on  Army 
C4I  architectures. 

The  research  was  conducted  within  the  Force  Development  and  Technology 
Program  of  RAND's  Arroyo  Center,  a  federally  funded  research  and 
development  center  sponsored  by  the  United  States  Army.  The  report  will  be  of 
interest  to  those  who  are  seeking  better  ways  to  help  commanders  perform  their 
missions  to  ensure  the  Army  can  meet  future  challenges.  Specifically,  it  will 
contribute  to  those  responsible  for  implementing  the  Army  Enterprise  Vision,  the 
Army  Digitization  Office,  the  Battle  Command  Battle  Laboratory,  and  those 
associated  with  the  development  of  Force  XXI  operations. 


Contents 


Preface .  iii 

Figures .  vii 

Tables  .  ix 

Summary .  xi 

Acknowledgments .  xxi 

Abbreviations . xxiii 

1.  INTRODUCTION .  1 

Background .  1 

Objective .  1 

Organization  of  This  Document .  2 

2.  DERIVING  OPERATIONAL  OBJECTIVES  FOR  C^TM .  3 

What  ODS  Revealed  About  C2  .  3 

Summary  of  ODS  C2  Difficulties .  3 

Implied  Needs  from  ODS  Findings .  4 

Relevant  Findings  from  Previous  RAND  Work . 6 

What  the  Future  May  Bring .  7 

Derived  Operational  Objectives .  7 

3.  DERIVING  INFORMATION  AND  PHYSICAL  REQUIREMENTS 

FOR  THE  OPERATIONAL  OBJECTIVES .  9 

Informational  Needs .  9 

Physical  Needs .  10 

Ranges  of  Quantifiable  Measures  for  Informational  and  Physical 

Needs .  11 

Ranges  of  Measures  for  Informational  Needs .  11 

Ranges  of  Measures  for  Physical  Needs .  12 

4.  ANALYSIS  OF  THE  ARMY'S  CURRENT  AND  PLANNED  C4 

SUBARCHITECTURE .  14 

Basic  Components  of  a  C4  Subarchitecture .  14 

The  Army's  Current  C4  Subarchitecture .  14 

The  Army's  Evolving  C4  Subarchitecture .  16 

Evaluating  the  Army's  Current  and  Evolving  C4  Subarchitectures 

Against  Informational  and  Physical  Needs .  18 

5.  COMPUTER-TO-COMPUTER  COMMUNICATIONS  (CtC) .  19 

Using  CtC  Exchanges .  19 

Current  and  Evolving  CtC  Military  Applications .  20 

6.  SWITCHBOARD  IN  THE  SKY  (SIS) .  25 

The  SIS  Concept .  25 

The  SIS  Architecture .  26 

The  Collection,  Production,  and  Dissemination  Facility .  27 


vi 


The  Overhead  Relay  and  Switch  ....  —  ....  —  ........... 

Command  and  Control  Vehicles  . . 

Postulated  SIS  Performance  . . * . . 

Informational  Needs  . . . 

Physical  Needs  . . . 

Considerations  for  SIS  Concept  Cost  and  Performance  Trade-Off 

Analysis. . . . . . . 

Considerations  for  SIS  Location  Options  . . . 

Considerations  for  Message-Switching  System  Options . 

Considerations  for  Message-Storage  System  Options  . . 

Other  Considerations . 

7.  COMMON  PICTURE  OF  THE  OPERATION . 

Defining  a  CPO  and  Its  Purpose  . . . . . . . 

What  It  Is . 

What  It  Does  . . . . 

Generating  and  Disseminating  the  CPO . 

Defining  Commanders'  Information  Needs  . . . 

Benefits  of  a  CPO . 

8.  CONCLUSIONS  AND  RECOMMENDATIONS . . 

Conclusions . 

Recommendations  . . . . . 

Appendix 

A.  CONCEPT  FOR  ACQUIRING  NEW  INFORMATION 

TECHNOLOGIES  IN  DISCRETE  STEPS . 

B.  CONCEPT  FOR  SPACE-BASED  PLATFORM  PROXIES  FOR 

BATTALION-LEVEL  TRAINING  AT  THE  NATIONAL  TRAINING 
CENTER . 

Bibliography . * . *  • 


29 

31 

32 

32 

33 

33 

34 

35 

35 

36 

37 
37 

37 

38 

39 

40 
42 

44 

44 

45 


49 


51 

55 


Vll 


Figures 

4.1.  The  Army's  Current  C4  Subarchitecture .  15 

4.2.  Schematic  of  the  Army's  C4  Subarchitecture  Configuration .  16 

4.3.  Army's  Evolving  C4  Subarchitecture .  17 

6.1.  Schematic  of  the  Switchboard  in  the  Sky .  27 

6.2.  Ground  Coverage  of  a  Notional  Island  from  a  Relay  on  an  Aerial 

Platform  at  Altitudes  of  1, 6.6,  and  13.2  km .  31 

A.l.  Postulated  Acquisition  Gap  Between  Technology  and 

Capabilities,  Linear  Acquisition  Model .  50 

A. 2.  Postulated  Gap  Between  Technology  and  Capabilities 

Acquisition,  Epoch  Acquisition  Model  .  50 

B. l.  Obscuration  of  the  Lower  Region  of  the  Central  Corridor .  53 

B.2.  Range  of  Sensor  Coverage  by  Height .  54 


IX 


Tables 

3.1.  Informational  and  Physical  Needs  of  C4  Subarchitectures .  10 

4.1.  Apparent  Shortfalls  in  Informational  Needs  of  Army's  Current 

and  Evolving  Subarchitecture .  18 

4.2.  Apparent  Shortfalls  in  Physical  Needs  of  Army's  Current  and 

Evolving  Subarchitecture .  18 

6.1.  Key  Factors  Related  to  SIS  Performance  and  Cost  Trade-Offs .  34 

B.l.  Coverage  of  the  NTC  Central  Corridor  as  a  Function  of  Sensor 

Altitude .  53 


xi 


Summary 


Introduction 

The  uncertainty  in  the  changing  world  situation  and  the  diversity  of  crisis 
situations  U.S.  forces  may  face  in  the  future  reinforce  the  need  for  force 
commanders  at  all  levels  to  be  better  able  to  command  and  control  their  forces, 
particularly  at  the  operational  and  tactical  levels.  By  being  able  to  execute 
command  and  control  (C2)  rapidly,  effectively,  and  continuously,  forces  may  be 
able  to  quell  disturbances  in  early  stages  and  perhaps  limit  the  need  for  larger 
forces  or  for  longer  operations. 

With  improved  C2  as  a  goal,  this  document  presents  the  results  of  a  concept- 
formulation  study  that  took  an  initial  look  at  the  command  and  control  on  the 
move  (C2OTM)  situation  as  a  whole,  postulated  a  set  of  operational  objectives 
derived  from  experiences  in  Operation  Desert  Storm  (ODS)  and  from 
observations  based  on  past  RAND  research  in  the  area,  and  reviewed  the  Army's 
current  and  evolving  C2  subarchitecture1  against  these  objectives.  The  document 
also  suggests  some  elements  that  can  help  any  C2  subarchitecture  better  meet  the 
postulated  operational  objectives. 


Deriving  Operational  Objectives  for  C2OTM 

ODS  Lessons  Learned 

During  Operation  Desert  Storm  (ODS),  battlefield  information — which  included 
intelligence  and  data  on  friendly  force  location  and  status,  terrain  and  weather, 
battle  damage  assessment,  and  combat  service  support  (CSS) — was  delayed  in 
getting  to  commanders.  Command  posts  (CPs)  were  unwieldy.  In  addition, 
communications  and  automation  facilities  were  slow  to  deploy  to  the  region  and 
were  not  always  able  to  keep  up  with  fast-moving  tactical  units.  This  was  partly 
because  Mobile  Subscriber  Equipment  (MSE)  was  unable  to  keep  pace  with  the 
maneuver  units,  and  the  range  of  the  combat  net  radio  was  insufficient  to 
support  mobile  operations  in  such  a  large  region.  Moreover,  the  flow  of  data 


1 A  distinction  is  made  between  the  meta-architecture  that  includes  all  DoD  system  networks 
and  the  subordinate  architectures  referred  to  in  this  report,  which  are  called  C4  subarchitectures. 
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between  sources  and  users  was  not  streamlined  or  smooth,  because  ODS  relied 
on  a  large  variety  of  systems  and  diverse  software  controlled  by  various 
Department  of  Defense  agencies  that  differed  in  communications  media, 
operating  procedures,  standards,  and  protocols.  Beyond  this,  sufficient 
awareness  of  the  situation  among  all  commands  was  also  lacking.  There  was  no 
common  picture  of  the  operation  (CPO)  at  the  same  time  either  vertically  or 
horizontally  across  command  levels,  and  because  the  Global  Positioning  System 
(GPS)  was  not  integrated  into  the  operating  systems,  there  was  no  accurate, 
timely,  or  uniform  assessment  of  the  friendly  force  status  or  locations  of  units. 

These  findings  imply  the  following  needs:  (1)  timely  reports  for  C2  during 
mobile  operations;  (2)  smaller,  more  mobile  CPs;  (3)  automated  reporting  of 
friendly  asset  location  to  help  counter  fratricide;  and  (4)  range  extension  for  the 
Combat  Net  Radio  (CNR). 

Observations  from  Other  RAND  Research 

This  study  took  advantage  of  experience  and  knowledge  gained  from  a  series  of 
RAND  studies,  including  studies  of  conflict  scenarios  and  contingency 
operations,  mobile  operations,  CP  structure,  communications,  space-based 
systems,  automation,  image  displays,  sensors,  quantifying  and  measuring  system 
capabilities  in  operational  outcome  terms,  and  performing  system  trade-offs. 

These  studies  suggested  (1)  that  the  connection  architecture  for  the  intelligence 
system  lacked  responsiveness;  (2)  that  the  MSE  required  a  lot  of  time  to  deploy 
and  could  not  keep  pace  with  maneuver  units  when  they  were  engaged  in 
combat  (a  finding  confirmed  during  ODS);  (3)  that  commanders  prefer  imagery 
to  written  messages  and  desire  that  information  be  simultaneously  broadcast  to 
units  participating  in  the  same  operation,  rather  than  relayed  serially  through  the 
chain  of  command;  and  (4)  that  the  heavy  reliance  on  space  communications 
during  Operation  Urgent  Fury  and  ODS,  which  included  leased  commercial 
terminals  and  transponders  like  the  International  Telecommunications  Satellite 
(INTELSAT),  offered  many  advantages  (e.g.,  wide  area  coverage,  the  ability  to 
exchange  imagery,  and  increased  ground  mobility). 

Future  Operating  Conditions 

We  assumed  that,  in  the  future,  there  will  often  be  rapid  deployment  to  regions 
where  units  will  converge  and  meet  for  the  first  time  and  that  combat  and 
noncombat  operations  will  sometimes  take  place  concurrently  in  the  same  region. 
We  further  assumed  that  joint  and  combined  elements  will  need  to  work  closely 
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together  to  synchronize  operations;  that  these  operations  will  be  complicated  by 
differences  in  equipment,  doctrine,  software,  standards,  and  procedures;  that 
connectivity  will  have  few  interfaces  between  nodes;  and  that  architectures  will 
furnish  continuous  connectivity  between  deployed  forces  and  the  sustaining  base 
in  CONUS  and  possibly  an  active  region. 

Operational  Objectives  for  C2 

From  the  observations  and  assumed  future  operating  conditions  noted  above,  we 
postulated  eight  operational  objectives  for  C2  architectures: 

•  The  ability  to  deploy  forces  rapidly  to  any  region  in  the  world, 
unencumbered  by  excessive  equipment  and  its  operators 

•  Intraregional  C2  mobility  equal  to  or  greater  than  that  of  the  deployed  forces 

•  Infrastructure  for  C2  in  place  in  the  region  ahead  of  the  operational  forces 
and  operating  as  soon  as  it  is  needed 

•  Reports  about  the  environment,  enemy  location,  activities,  and  targets,  and 
location  and  status  of  friendly  forces  available  to  commanders  and  their 
staffs  at  all  times 

•  Reports  about  the  situation  to  protect  and  sustain  the  force  available  at  all 
times  regardless  of  mission,  including  noncombat  operations 

•  Position  location  at  the  small-unit  and  vehicle  levels,  automatically  collected, 
analyzed,  and  disseminated  to  one  or  more  central  locations  to  help  guard 
against  fratricide 

•  The  ability  to  assimilate  forces  in  deployed  commands  rapidly  and 
continuously  and  to  disseminate,  exchange,  and  display  essential  data 
during  nonconflict  periods  while  forces  are  assembling  and  preparing  for 
operations 

•  Intelligent  displays  with  decision  support  aids  at  command  levels  down  to 
battalion. 


Deriving  Information  and  Physical  Requirements  for 
the  Operational  Objectives 


Given  these  operational  objectives,  we  identified  a  set  of  informational  and 
physical  needs  that  the  components  of  any  command,  control,  communications, 
and  computers  (C4)  architecture  must  satisfy. 
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Informational  Needs 

The  subarchitectures  and  their  systems  must,  first,  furnish  the  information 
needed  to  support  commanders'  current  and  planned  operations  (ie.,  reports 
that  are  timely,  accurate,  relevant,  and  understandable).  Second,  the  reports 
generated  by  the  subarchitectures  and  their  systems  must  be  readily  understood 
by  joint  forces,  so  they  can  be  interoperable  and  comprehensible  by  all  the 
participating  Services,  combined  forces,  and  civilian  agencies,  when  necessary. 
Third,  the  reports  must  be  comprehensive,  including  all  categories  of  reports 
needed  to  support  operational  planning  and  decisionmaking.  Fourth,  they  must 
be  responsive  to  commanders'  tasking  to  meet  their  changing  needs. 


Physical  Needs 

The  communications  equipment  and  systems  that  comprise  the  subarchitectures 
must,  first,  be  readily  available  to  rapid  deployment  forces.  Second,  they  must  be 
self-sustaining  (i.e.,  able  to  operate  in  a  region  that  has  little  or  no  available 
infrastructure).  Third,  they  must  be  as  mobile  as  the  forces  they  support,  perhaps 
with  ground  terminals  mounted  in  high-mobility  multipurpose  wheeled  vehicles 
or  in  helicopters.  Fourth,  they  must  be  adaptable  to  rapid  and  sudden  changes  in 
the  environment  and  in  the  conflict  situation,  as  well  as  to  changes  in  the  types 
and  numbers  of  users,  and  the  mission.  Fifth,  they  must  be  reliable  and  robust 
(i.e.,  they  must  be  sufficient  for  continuity  of  operations,  balancing  reliability  of 
support  and  mobility  reduction;  must  be  self-restoring;  and  must  help  CPs 
survive  by  not  emanating  telltale  signatures,  and  by  incorporating 
communications  security  and  anti-jamming  capabilities.  Sixth,  they  must  both 
support  and  be  supported  across  the  CSS  spectrum. 

One  final  need,  which  is  neither  informational  or  physical  (but  which  is  critical) 
is  that  the  architectures  and  their  systems  that  provide  these  capabilities  must  be 
affordable. 

Ranges  of  Quantifiable  Measures  for  Informational  and  Physical 
Needs 

Although  we  did  not  actually  measure  the  above  informational  and  physical 
needs,  we  did  examine  a  range  of  measures  for  each  one.  For  example,  for  the 
first  informational  need,  "Supportive  of  operations,"  potential  quantifiable 
measures  include  timeliness,  accuracy,  and  adequacy  of  data  to  enable  planning 
and  decisionmaking.  And  the  first  physical  need,  "Available,"  has  a  time 
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dimension  that  ranges  from  having  the  C4  equipment  in  the  region  before  early 
entry  forces  arrive  to  arriving  with  or  after  those  forces. 


Analysis  of  the  Army's  Current  and  Evolving  C4 
Subarchitecture 

The  Army's  current  C4  architecture  is  based  on  the  C2  Mini-Functional  Area 
Analysis  Study  and  the  Military  Satellite  Communications  (MILSATCOM) 
Architecture  Study.  It  is  based  on  the  philosophy  that  reports  from  all,  or  as 
many  as  possible,  of  the  numerous  inter-  and  intraregional  systems  should  go 
directly  to  the  commanders  and  their  staffs. 

While  the  rationale  for  the  current  architecture  is  good,  it  does  not  do  a  very 
good  job  of  meeting  the  informational  and  physical  needs  discussed  above. 
Specifically,  it  contains  an  ever-increasing  number  of  diverse  systems,  which 
makes  it  impractical  to  accommodate.  As  a  result,  it  lacks  interoperability  within 
itself,  with  the  other  Services,  and  with  U.S.  allies  and  friends.  Although  it  can 
supply  data  and  reports  from  several  different  subarchitectures  to  commanders 
in  the  field,  the  data  and  reports  must  be  first  integrated  before  they  can  be  used 
to  determine  relevance  to  current  or  planned  operations.  Not  only  are  these  data 
different  at  the  standards,  format,  and  protocol  levels,  which  blocks  physical 
interoperability,  they  are  also  structured  differently  to  conform  to  data  standards 
according  to  individual  functional  domains  (stovepiping).  Consequently,  the 
Army's  present  C4  architecture  is  inefficient  in  terms  of  its  configuration, 
equipment,  and  personnel,  which  can  delay  decisionmaking  and  risk 
unnecessary  exposure  to  personnel. 

The  Army  is  evolving  its  current  architecture  by  integrating  it  with  the  Army 
Tactical  Command  and  Control  System.  In  this  architecture,  the  CPs  and  the 
command  and  control  vehicles  (C2Vs)  receive  data  from  a  variety  of  collection, 
production,  and  dissemination  facilities  (CPDFs),2  each  devoted  to  a  particular 
function  (e.g.,  CSS,  intelligence,  and  other  situation  awareness  reports),  as  well  as 
from  a  number  of  sensors.  The  data  products  are  sent  to  users  in  the  region 
primarily  over  terrestrial  MSE  links.  The  architecture  would  be  augmented  by 
satellite  links,  and  although  there  are  plans  for  some  reports  to  be  broadcast  to 
users  and  some  space-based  systems  may  be  used  for  that,  the  plans  call  for 
doing  so  only  for  specific  kinds  of  data  along  certain  functional  domain  lines 
(e.g.,  warnings),  rather  than  for  all  kinds  of  data. 


2The  CPDF  is  a  term  we  coined  to  describe  a  central  place  where  all  source  collection, 
production,  and  dissemination  operations  are  performed  and  standard  and  special  types  of  reports 
are  prepared  and  disseminated. 
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Notwithstanding  these  incremental  improvements,  this  subarchitecture  is 
unwieldy  and  difficult  to  control,  primarily  because  various  kinds  of  data  and 
formats  from  different  data  sources  all  converge  at  different  times  and  at  a  single 
place  for  the  commander  to  integrate  and  try  to  make  sense  of.  This  means  that  a 
C2V  for  the  commander  and  his  staff  would  probably  require  a  multitude  of 
different  receivers  and  antennas  to  receive  reports  from  all  the  different  CPDFs 
and  sensors,  and  the  large  number  of  transceivers  with  associated  radio 
frequency  bands  and  antennas  would  adversely  affect  the  CP  s  survivability  and 
the  C2Vs'  mobility.  In  addition,  this  subarchitecture  is  still  divided  into 
physically  dispersed  processing  centers  set  up  according  to,  and  optimized  for, 
the  functional  domains  (e.g.,  CSS,  intelligence,  fire  support)  and  their  unique 
sub-subarchitectures.  Finally,  deploying  the  large  amounts  of  diversified 
equipment  required  at  each  CP  would  involve  many  operators  and  high  costs. 


Ideas  for  Optimizing  C4  Architectures 

Given  the  shortfalls  in  the  Army's  current  and  evolving  C4  architecture,  we 
examined  some  ideas  for  optimizing  C4  architectures  to  help  them  meet  the 
informational  and  physical  needs. 


Computer-to-Computer  Communications 

A  major  drawback  to  C2  efficiency  is  that  data  transfers  between  computers 
currently  take  place  over  architectures  that  are  not  optimized  for  such  transfers. 
In  the  past,  except  for  Air  Defense  subarchitectures,  all  communications  required 
the  direct  action  of  operators  at  both  the  sending  and  receiving  ends.  Now, 
many  data  exchanges  are  automated,  taking  place  much  faster  than  humans  can 
assimilate  or  act  upon. 

Differentiating  between  the  architectures  for  person-to-person  communications 
and  those  for  automated  computer-to-computer  (CtC)  data  exchanges  may  be  a 
valuable  concept.  Such  CtC  exchanges,  especially  digital  data  transmission,  are 
definitely  on  the  rise  and  are  expected  to  increase.^  Some  current  and  evolving 
examples  for  military  applications  include  the  following: 


Subsequent  to  this  study,  the  Army  initiated  a  major  effort  to  digitize  the  battlefield.  This  effort 
is  being  managed  by  the  Army  Digitization  Office  as  part  of  the  Force  XXI  activities.  Three  major 
exercises  are  included  in  the  plan:  a  digitized  Battalion  Task  Force  XXI  (94),  a  digitized  Brigade  Task 
Force  XXI  (97),  and  a  digitized  Division  XXI  (99).  The  digitization  of  the  battlefield  initiative  is  one  of 
three  thrusts  the  Army  is  pursuing  to  achieve  Force  XXI. 
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•  On-board  data  processing 

•  Automated  unmanned  aerial  vehicle  operations 

•  Automated  data  relays  and  switches 

•  Integrated  GPS  receivers  connected  to  control  centers  by  line-of-sight  satellite 
relays 

•  Automated  logistics  tracking  and  inventorying 

•  Teleoperated  mines  and  unattended  data-linked  ground  sensors. 

In  particular,  CSS  would  benefit  from  automated  collection  of  data  on  equipment 
status  and  consumption  of  petroleum,  oil,  and  lubricants;  munitions;  and  other 
consumables  derived  from  on-board  sensors  connected  to  small,  low-cost 
transponders  installed  in  major  items  of  equipment.  The  transponders  would  be 
activated  either  automatically  or  upon  command  to  send  stored  data  periodically 
about  a  system's  status  and  performance  via  space-based  links  to  the  CPDF. 

Switchboard  in  the  Sky 

Another  idea  for  optimizing  C4  architectures  is  to  push  intelligence  and  other 
reports  from  the  sustaining  base  to  an  intermediate  point  that  is  either  actually  or 
virtually  above  the  active  region  in  which  operations  are  being  conducted.  We 
referred  to  this  point  as  a  "switchboard  in  the  sky"  (SIS),  which  can  be 
conceptualized  as  a  sort  of  "data  salad  bar"  that  would  allow  users  to  select  only 
those  reports  of  interest  to  them  and  in  the  amount  of  detail  relevant  to  their 
needs.  Thus,  the  problem  commanders  often  complain  about,  that  of 
"information  overload,"  can  be  avoided.  Instead,  a  commander  would  be  able  to 
access  what  he  wants  to  know  about  his  particular  area  selectively — including  his 
rear  area — or  the  entire  region  of  operations,  as  well  as  about  hostile  elements  on 
his  flanks,  to  the  rear  of  his  position,  or  deep  in  his  opponent's  rear  area,  without 
becoming  overloaded  with  nonessential  details  about  the  entire  region. 

We  also  elaborated  on  the  places  where  database  and  other  memory  storage 
would  reside.  The  SIS  concept  envisages  relaying  reports  containing  graphical 
images  with  amplifying  text  and  other  formats  to  users  in  the  region  by 
collecting,  updating,  and  storing  the  data  on  line  until  users  request  it.  Each 
CPDF  connected  to  the  relay  would  serve  as  a  central  clearing  house  for  data  in 
both  directions — to  users  in  the  format  and  resolution  they  require,  and  from 
users  to  the  sustaining  base  through  the  SIS  (e.g.,  CSS  consumption  by 
commodity  or  service  type  and  by  location). 
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Common  Picture  of  the  Operation 

Another  important  idea  to  help  optimize  C4  architectures  is  the  concept  for  a 
CPO.  Actually,  we  mean  a  unique  perception  created  in  the  mind  of  each 
recipient  of  data  with  the  help  of  reports  that  become  the  basis  for  decisions. 
Although  some  aspects  of  a  perception  can  be  shared  by  more  than  one  recipient 
of  the  same  data  or  report,  a  single  perception  cannot  truly  be  common.  The 
CPO  would  be  a  common  framework  for  data  and  standard  report  formats  in 
which  many  aspects  might  be  shared  among  recipients  by  means  of  a  common 
data  set.  The  reports  from  which  the  CPO  is  created  would  consist  of  details 
provided  in  response  to  the  stated  informational  needs  of  individual 
commanders  and  would  be  designed  to  reduce  the  uncertainty  about  their  own 
decision  space.4  This  process  envisions  using  information  agents  to  create  and 
update  commanders'  CPOs  and  presenting  most  of  the  data  to  be  exchanged 
between  individuals  in  soft  copy  image  formats,  e.g.,  maps,  overlays,  and 
annotations  (icons,  lines,  arrows,  numbers,  and  limited  text). 


If  the  same  data  standards  and  profiles  are  employed  by  all  the  Services,  the  use 
of  such  common  graphics  would  greatly  enhance  interoperability  for  joint 
operations,  since  graphical  displays  can  transcend  organizational  and  linguistic 
barriers.  In  addition,  the  objects  depicted  in  the  CPO  might  also  portray  safe 
routes  for  medical  evacuation  or  supply  movements  for  noncombat  operations, 
such  as  disaster  relief,  or  the  location  of  mines  and  the  capability  of  hostile  forces 
for  conducting  combat  operations. 


An  important  part  of  actualizing  the  CPO  concept  is  determining  commanders' 
information  needs.  This  could  be  accomplished  by  automatically  recording  the 


computer  operations  commanders  at  various  command  levels  perform  for  a 
particular  scenario  and  mission.  This  information  might  also  be  recorded 
according  to  the  type  of  unit,  since  the  sequence,  types  of  data,  and  amount  of 
detail  the  commanders  request  to  plan  or  execute  their  missions  will  reflect  their 
general  information  preferences  for  decisionmaking. 


Analysts  could  then  perform  sensitivity  analyses  to  determine  generally  what 
kinds  of  reports  are  needed  for  various  kinds  of  decisions  (e.g.,  for  planning, 
attacking,  and  defending),  as  well  as  what  types  of  reports  the  CPDFs  should 
prepare  and  how  often  to  disseminate  them.  The  results  of  these  kinds  of 
analyses  could  serve  as  tools  in  answering  engineering-design  questions  about  an 


4 Decision  space  refers  to  all  subject  matter  that  is  related  to  a  set  of  decisions  for  which  a 
decisionmaker  is  partially  or  totally  responsible  and  to  the  set  of  all  possible  decisions  the 
decisionmaker  may  make. 
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architecture's  design  for  data  acquisition  and  information  display  and  its 
supporting  systems  and  databases. 


Conclusions  and  Recommendations 

The  main  conclusion  of  this  concept-formulation  study  is  that  it  is  feasible  for 
joint  task  force  elements  to  operate  while  moving  by  adopting  new  techniques  to 
assess  information  requirements  and  new  technologies,  architectures,  systems, 
and  procedures,  particularly  space-based  systems.  This  requires  major  revisions 
to  the  current  architectures  that  connect  data  sources  with  data  users  in  a  region 
of  operations. 

Given  this  conclusion,  we  recommend  that  the  Army 

•  design,  in  conjunction  with  the  other  Services  and  DoD  agencies,  from  the 
top  down,  a  completely  new  open  architecture  (both  hardware  and  software) 
intended  primarily  for  C2 

•  use  a  common  data  structure  for  all  the  Army's  functional  domains  (e.g., 
intelligence,  maneuver,  CSS,  fire  support,  aviation,  air  defense) 

•  analyze,  once  the  new  architecture's  design  is  complete,  the  potential  utility 
of  all  equipment  and  software  currently  in  use  and  on  order  to  determine  its 
suitability,  using  the  Louisiana  Maneuvers  demonstration  program  and  the 
Army's  campaign  plan  for  Force  XXI  as  a  test  bed  for  such  evaluation 

•  discard  unsuitable  equipment  as  soon  as  possible  (to  reduce  legacy 
problems)  by  stopping  any  ongoing  production  and  replacing  each  with 
items  compatible  with  a  new  architecture 

•  look  for  potential  resources  from  industry  and  elsewhere  outside  the  Army 
by  conceptualizing  and  describing  new  applications  for  C2-related 
technologies  that  have  both  civilian  and  military  uses. 
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1.  Introduction 


Background 

With  the  collapse  of  the  Soviet  Union,  the  defense  guidance  and  planning  focus 
of  the  United  States  has  shifted  from  a  single  global  scenario  requiring  planning 
for  only  a  few  geographical  areas  to  an  array  of  operationally  and  geographically 
diverse  conflict  scenarios,  both  combat  and  noncombat.  This  focus  reinforces  the 
need  for  commanders  at  all  levels  to  be  better  able  to  command  and  control  their 
forces,  particularly  at  the  operational  and  tactical  levels.  With  the  current 
increased  emphasis  on  joint  and  combined  operations,  all  the  forces  must  be 
jointly  interoperable  (even,  at  times,  with  allied  forces),  and  commanders  must 
have  the  information  they  need  while  en  route  to  the  conflict  area,  as  well  as 
immediately  on  arrival  there — what  we  call  command  and  control  on  the  move 
((^OTM).1  By  being  able  to  execute  command  and  control  (C2)  rapidly, 
effectively,  and  continuously,  a  small  force  may  be  able  to  quell  a  disturbance  in 
its  earliest  stage  and  perhaps  limit  the  need  for  a  larger  force  or  for  a  longer 
operation. 

C^TM  considerations  often  center  on  a  vehicle  and  its  information-reception 
capabilities.  Information  content  received  is  also  vital,  of  course,  but  the 
information  requirements  of  decisionmakers  have  not  always  been  a  central 
focus.  Currently,  Services  either  own  or  have  access  to  a  variety  of  valuable 
databases  and  highly  capable  collection  systems.  Connecting  commanders  to  the 
data  they  want  is  proceeding  gradually  through  many  efforts,  but  effectiveness  is 
limited  by  inadequate  interoperability  within  and  across  Services  and  Army 
commands,  beginning  at  the  fundamental  level  of  data  elements  and  standards. 


Objective 

This  document  reports  the  results  of  a  concept-formulation  study  that  took  an 
initial  look  at  the  C2OTM  situation  as  a  whole.  More  specifically,  the  study 


^The  terms  C2OTM  and  mobile  communications  refer  to  having  sufficient  mobility  to  support 
operations  in  regions  effectively  and  efficiently  and  do  not  necessarily  mean  provision  of  operational 
(battle  command)  communications  to  units  at  all  command  levels  while  they  are  moving 
continuously.  C2OTM  is  primarily  needed  by  brigades  and  battalions  when  they  are  deployed  and 
by  corps  through  division  when  they  are  en  route  to  a  region. 
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addressed  what  a  C^OTM  system  would  need  to  be  able  to  do,  based  on  criteria 
derived  from  recent  experience  in  Operation  Desert  Storm  (ODS)  and  what  we 
have  observed  about  C2  in  past  RAND  projects.  We  then  use  these  criteria— both 
informational  and  physical— to  evaluate  the  Army's  current  and  planned  C2 
architecture.  After  that,  we  offer  some  suggestions  about  C2  elements  that  could 
be  used  to  better  meet  the  criteria,  then  provide  some  general  conclusions  and 
recommendations. 

Throughout  this  document,  we  use  the  word  information  in  the  context  of 
situational  knowledge  that  is  relevant  to  a  particular  decision  or  group  of  related 
decisions  needed  to  support  a  plan  or  to  execute  operations.  This  includes 
warning  to  protect  friendly  forces  in  a  given  area,  place,  and  time.  The 
information  content  supplied  by  any  architecture  cannot  be  the  same  for  all 
recipients,  because  each  user  has  different  decisions  to  address. 


Organization  of  This  Document 

Section  2  describes  what  we  learned  about  C2  in  ODS  and  sums  up  knowledge 
gained  from  other  RAND  research.  Section  3  postulates  operational  objectives 
for  command,  control,  communications,  and  computers  (C4)  and,  based  on  these, 
identifies  physical  and  informational  needs  that  architectures  for  C4  must  meet. 
Section  4  describes  the  Army's  current  C4  architecture  and  compares  the 
architectures  qualitatively  against  the  needs  identified  in  Section  3.  Sections  5, 6, 
and  7  examine  some  elements  that  can  help  meet  the  criteria  defined  earlier — 
specifically,  the  concept  of  a  "switchboard  in  the  sky"  (SIS),  the  role  of  eomputer- 
to-computer  (CtC)  data  exchanges  in  optimizing  their  architectures,  and  the 
concept  of  a  common  picture  of  the  operation  (CPO)  and  of  how  it  can  be  used  to 
accurately  determine  commanders'  information  needs  and  preferences.  Finally, 
Section  8  provides  some  conclusions  and  recommendations. 

Appendix  A  describes  a  concept  for  acquiring  new  information  technologies  in 
discrete  steps,  and  Appendix  B  describes  a  concept  for  employing  space-based 
proxy  platforms  at  the  National  Training  Center. 
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2.  Deriving  Operational  Objectives  for 
C2QTM 


To  take  an  initial  look  at  the  C^TM  situation  as  a  whole,  we  began  by  deriving 
some  operational  objectives  for  C2  based  on  what  ODS  revealed,  what  past 
RAND  research  showed,  and  what  our  assumptions  about  the  future 
environment  portend. 


What  ODS  Revealed  About  C2 

One  of  the  lessons  of  ODS  was  that  the  performance  of  the  tactical-level  C2 
component  of  the  current  architecture  for  tactical  C4  was  inadequate  to  support 
mobile  combat  operations  (House  Armed  Services  Committee,  1992).  This 
occurred  primarily  because  the  current  system  was  optimized  to  support  a 
European  or  Korean  scenario  that  envisioned  limited  force  mobility  and 
operations  in  depth.  Below,  we  first  summarize  those  difficulties,  then  discuss 
the  needs  they  imply. 

Summary  of  ODS  C2  Difficulties 

During  ODS,  essential  battlefield  data — including  intelligence,  tactical  ballistic 
missile  warning,  friendly  force  location  and  status,  terrain  and  weather,  battle 
damage  assessment,  and  combat  service  support  (CSS)  data — were  delayed  in 
getting  to  commanders.  Command  posts  (CPs)  for  combat  units  were  unwieldy 
and  were  not  optimal  for  supporting  mobile  operations.  Communications  and 
automation  facilities  were  slow  to  deploy  to  the  region  and  to  redeploy  when 
they  arrived.  Mobile  subscriber  equipment  (MSE)  was  unable  to  keep  pace  with 
the  maneuver  units.1  In  addition,  the  range  of  the  combat  net  radio  (CNR)  was 
insufficient  to  support  mobile  and  deep  operations  at  division  and  above. 
Moreover,  various  agencies  controlled  a  large  variety  of  databases  and  systems, 
which  meant  the  databases  and  systems  differed  in  communications  media, 
software  data  and  control  standards,  and  protocols  for  data  sharing  and 
connectivity.  As  a  result,  the  flow  of  data  between  sources  and  users  was  not 


1  During  ODS,  MSE  was  fielded  to  only  two  divisions.  The  Tri-Service  Tactical  Communications 
system,  which  employs  an  architecture  different  from  that  of  MSE  and  does  not  interoperate  well 
with  it,  had  to  be  adapted  with  interface  equipment  and  software  to  be  connected  to  MSE  nodes. 
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streamlined  or  smooth.  This  meant  that  operators  had  to  devote  much  of  their 
time  to  configuring  a  modified  architecture  to  achieve  interoperability  between 
systems,  instead  of  being  able  to  use  an  in-place  architecture  designed  for 
interoperability  to  perform  their  operational  missions.  There  was  also  no  CPO  at 
the  same  time,  either  within  or  across  command  levels.  Reports  required  to 
promote  better  awareness  of  the  current  situation  across  all  commands  were 
lacking.  There  was  often  no  accurate,  timely,  or  uniform  assessment  of  the 
friendly  force  status  or  locations  of  units.  The  Global  Positioning  System  (GPS) 
was  not  integrated  into  the  operating  systems  so  that  commanders  could  know 
where  their  unite  and  key  elements  were  situated  at  all  times. 

Many  of  the  deficiencies  identified  above  are  procedural  and  operational  rather 
than  tactical.  Thus,  the  greatest  benefit  to  the  Services'  ability  to  conduct 
operations,  especially  joint  operations,  would  derive  from  policy  changes  at  both 
the  operational  and  tactical  levels. 


Implied  Needs  from  ODS  Findings 

Timely  Reports  for  C2  During  Mobile  Operations.  A  key  finding  was  that 
situation  awareness  is  critical  to  promoting  C2  agility,  particularly  in  a  mobile 
operation.  The  commander  must  stay  abreast  of  the  friendly-and-enemy 
situation  to  make  the  rapid,  informed  decisions  necessary  to  maintain 
momentum,  exploit  opportunities,  and  prevent  fratricide.  This  means  that 
tactical  CPs  at  brigade  and  battalion  must  continue  to  receive,  process,  and 
transmit  timely  information  while  they  are  moving,  to  provide  a  current  picture 
of  the  operation  at  all  times  for  all  commanders  and  their  staffs.2 
Communications  and  automation  must  enable  the  commander  to  be  kept 
informed  of  critical  information  and  to  be  alerted  to  situations  requiring  quick 
decisions.  Commanders  need  the  most  current  perception  of  the  operation, 
tailored  by  them  to  their  problems  or  the  decisions  they  are  preparing  to  make, 
with  an  alerting  override  when  they  need  to  be  confronted  with  new  and 
unanticipated  data  they  must  deal  with  immediately,  or  when  various  inputs 
exceed  a  chosen  threshold.  The  alerting  function  is  what  allows  the  commander 
to  allocate  his  attention  and  to  help  avoid  information  overload  in  any  particular 
category. 

Smaller,  More  Mobile  Command  Posts.  Another  key  ODS  communications 
finding  was  that  the  current  CP  configuration  of  tactical,  main,  and  rear  was  not 
optimal  for  supporting  mobile  operations.  Corps,  division,  and  brigade 


2Hence,  the  Army's  Battle  Command  Vehicle  (BCV)  concept 
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commanders  apparently  need  a  small,  mobile  forward  CP  electronically  linked  to 
a  larger,  generally  static  rearward  CP.  The  forward  CP  would  focus  primarily  on 
the  operation  and  synchronization  of  close  and  deep  operations,  while  the 
rearward  CP  would  perform  detailed  analysis,  coordination,  and  planning,  as 
well  as  conduct  rear  operations. 

Given  that  it  is  feasible  to  link  rearward  and  forward  CPs  electronically  over  a 
relatively  long  distance,  in-theater  operations  could  be  supported  from  a 
relatively  secure  "split-base"  structure  in  which  the  rear  base  could  be  located  in 
or  outside  the  continental  United  States  (CONUS).  Certain  intelligence,  logistics, 
personnel  service  support,  and  deployment  or  redeployment  operations  could  be 
supported  by  a  static,  nondeployable  headquarters. 

Automated  Reporting  of  Friendly  Asset  Location  to  Help  Counter  Fratricide. 
GPS  proved  to  be  a  tremendous  C2  asset  during  ODS,  since  it  provided  users 
with  highly  accurate  unit  location  data.  However,  it  did  not  automatically 
update  commanders  on  their  units'  positions.  While  the  units  knew  their  own 
locations  more  accurately  than  ever  before,  the  data  still  had  to  be  reported 
manually,  and  there  was  no  central  location  that  automatically  received, 
aggregated,  and  disseminated  position  updates  to  others  (e.g..  Air  Force  and 
Naval  strike  teams)  who  needed  it.  To  be  most  useful  for  countering  fratricide, 
position  location  of  friendly  forces  and  their  assets  must  be  automatically 
communicated  and  displayed  at  CP  and  fire  control  centers.  These  data  would 
also  be  valuable  to  alert  Air  Force  and  Naval  units  of  the  precise  locations  of 
friendly  ground  units  to  aid  in  preventing  fratricide.3 

Range  Extension  for  the  CNR.  Another  of  the  ODS  communications  findings 
was  that  short-range  CNR,  while  adequate  to  support  brigades  and  battalions, 
requires  range  extension  to  meet  division  requirements.  The  best  long-range 
CNR  appears  to  be  tactical  satellite  (TACSAT)  or  equivalent.  However,  a 
TACSAT  system  is  currently  not  operable  while  moving,  and  future  channel 
availability  and  responsiveness  are  problematic.  High-frequency  radios  are  not 
sufficiently  reliable  to  support  command  communications.  In  addition,  MSE 
provides  unreliable  or  tenuous  support  to  brigades  during  rapid  and  long- 


subsequent  to  ODS,  additional  units  of  the  Position  Lightweight  GPS  Receiver,  a  handheld  GPS 
receiver  that  enables  accurate  position  location  to  be  readily  made  available  to  its  users,  were 
procured,  and  approval  was  authorized  to  develop  the  GPS  ABCS  Tracking  System  to  track 
individual  mobile  equipment  for  asset  and  resource  monitoring,  e.g.,  armored  vehicles  and  other 
weapons.  However,  as  yet,  there  is  no  system  for  automatically  identifying  and  reporting  the 
location  of  such  equipment  to  control  centers  to  help  counter  the  fratricide  problem  experienced  in 
ODS.  However,  the  current  Army  initiative  to  digitize  the  battlefield  is  procuring  applique  hardware 
for  a  variety  of  battlefield  equipment.  The  applique  hardware  is  to  include  a  communication  device, 
a  position  locator,  a  computer  processor,  and  a  display  and  input  device. 
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distance  movement,  because  its  nodes  lack  the  necessary  agility  to  provide 
consistent  and  robust  support  to  forward  units. 


Relevant  Findings  from  Previous  RAND  Work 

As  mentioned  in  the  previous  section,  this  study  took  advantage  of  experience 
and  knowledge  gained  from  a  series  of  RAND  studies,  including  studies  of 
conflict  scenarios  and  contingency  operations,  mobile  operations,  CP  structure, 
communications,  space-based  systems,  automation,  image  displays,  sensors, 
quantifying  and  measuring  system  capabilities  in  operational  outcome  terms, 
and  performing  system  trade-offs.  The  following  reports  were  particularly 
useful: 

•  Difining  Commanders'  Information  Needs  (Kahan,  Worley,  and  Stasz,  1989) 

•  Support  for  the  Army  Intelligence,  Electronic  Warfare,  and  Target  Acquisition 
Master  Plan  (Cesar,  1988) 

•  Recommended  Strategy  for  the  Army's  Role  in  Space  (Harris,  Horn,  Cesar,  and 
Steinberg,  1993) 

•  Estimating  the  Army's  Intelligence  Requirements  and  Capabilities  for  1997-2001: 
Analytic  Support  to  the  Military  Intelligence  Relook  Task  Force  (Bondanella  et  al., 
1993) 

•  A  New  Approach  for  Measuring  the  Operational  Value  of  Intelligence  for  Military 
Operations  (Cesar  et  ah,  1993). 

The  MI  Relook  Study  was  particularly  relevant.  It  determined  that,  dining  ODS, 
the  intelligence  system  connection  architecture  lacked  responsiveness  and  that 
the  MSE  took  a  lot  of  time  to  deploy  and  could  not  keep  pace  with  maneuver 
unite  when  they  were  engaged  in  combat.  The  research  also  revealed  that 
commanders  prefer  imagery  to  written  messages  and  prefer  information  to  be 
simultaneously  broadcast  to  unite  participating  in  the  same  operation,  rather 
than  relayed  serially  through  the  chain  of  command. 

In  other  studies,  researchers  learned  that  the  heavy  reliance  on  space 
communications  during  Operation  Urgent  Fury  and  ODS,  which  included  leased 
commercial  terminals  and  transponders,  such  as  the  International 
Telecommunications  Satellite  (INTELSAT),  offered  many  advantages  (e.g.,  wide 
area  coverage,  the  ability  to  exchange  imagery,  and  increased  ground 
mobility)(Harris,  Horn,  Cesar,  and  Steinberg,  1993). 
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What  the  Future  May  Bring 

In  deriving  C2  operational  objectives,  we  made  some  assumptions  about  the 
likely  complexities  of  the  future  operating  environment.  For  example,  we 
assumed  the  following: 

•  There  will  often  be  rapid  deployment  to  regions  where  units  of  hastily 
assembled  task  forces  will  converge  and  meet  for  the  first  time. 

•  Combat  and  noncombat  operations  will  sometimes  take  place  concurrently  in 
the  same  region. 

•  Joint  and  combined  elements  will  need  to  work  closely  together  to 
synchronize  training,  deployments,  and  operations. 

•  Joint  efforts  will  be  complicated  by  differences  in  equipment,  doctrine, 
software,  standards,  and  procedures. 

We  also  recognize  the  difficulties  of  ensuring  that  commanders  are  always 
connected  to  sources  of  information  through  all  phases  of  deployment  and 
campaigns.  These  difficulties,  we  assume,  will  be  reduced  as  the  Army  alleviates 
its  problems  with  the  following: 

•  Maintaining  uninterrupted  systems  and  communications  service  while  on 
the  move 

•  Arranging  handoffs  to  different  agencies  while  en  route 

•  Reducing  the  time  and  effort  of  setup,  connection,  tear-down,  and 
safeguarding  C2  systems  and  communication  equipment 

•  Providing  continuous  connectivity  and  data  flows  to  the  sustaining  base  and 
intermediate  commands 

•  Minimizing  the  interfaces  required  for  all  connectivity  (e.g.,  buffers, 
translators,  specialized  software)  to  achieve  seamless  interface  and 
transparent,  unburdensome,  and  continuous  support  to  commanders. 


Derived  Operational  Objectives 

Many  of  the  deficiencies  identified  above  are  operational  rather  than  tactical. 
Thus,  the  greatest  benefit  to  the  Services'  ability  to  conduct  operations,  especially 
joint  operations,  would  derive  from  changes  at  both  the  operational  and  the 
tactical  levels.  Consequently,  this  study  focused  on  the  operational  level. 
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From  these  findings  and  implied  needs  from  ODS,  findings  from  previous 
RAND  research,  and  assumptions  about  the  future  operating  environment,  we 
postulated  the  following  operational  objectives  for  C^OTM: 


•  The  ability  to  deploy  forces  rapidly  to  any  region  in  the  world,  including 
CONUS  and  U.S.  possessions 

•  Intraregional  mobility  equal  to  or  greater  than  that  of  the  forces 

•  Infrastructure  for  C2  in  place  in  the  region  ahead  of  or  at  least  simultaneously 
with  the  arrival  of  operational  forces  and  operating  as  soon  as  it  is  needed 

•  Reports  about  tire  environment,  enemy  locations  and  activities,  and  the 
location  and  status  of  friendly  forces  available  to  commanders  and  their 
staffs  at  all  times 

•  Data  needed  to  protect  and  sustain  the  force  at  all  times  regardless  of 
mission,  including  noncombat  operations 

•  Position  location  at  the  small-unit  and  vehicle  levels,  automatically  collected, 
analyzed,  and  disseminated  to  and  by  one  or  more  central  locations  to  help 
guard  against  fratricide. 

While  we  believe  the  Army  will  find  merit  in  these  postulated  C2  operational 
objectives,  we  believe  the  Army  itself,  in  conjunction  with  the  other  Services, 
needs  to  describe  its  operational  objectives  by  continually  reexamining  the 
informational  data  requirements  of  commanders  for  performing  C2  and  by 
defining  the  anticipated  movement  dynamics  of  the  forces  in  future  operational 
settings.  We  believe  the  Army  should  specify  and  continually  update  and  revise 
the  required  data,  by  type,  and  should  identify  tire  providers  and  intended 
recipients  of  databases  and  messages  necessary  for  C2,  plus  the  desired  message 
formats,  content,  volume,  and  timeliness  expectations. 
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3.  Deriving  Information  and  Physical 
Requirements  for  the  Operational 
Objectives 


Given  the  operational  objectives  postulated  in  Section  2,  we  identified  the 
following  set  of  informational  and  physical  needs  that  the  components  of  any  C4 
architecture  must  satisfy. 


Informational  Needs 

Fulfilling  a  commander's  information  needs  is  the  primary  basis  for  C4  system 
requirements.1  Information  reduces  uncertainty  in  the  decision  space2  of  a 
recipient.  Data  are  not  necessarily  information  and  neither  data  nor  information 
are  knowledge,  although  these  terms  are  often  interchanged.  If  the  decision 
space  is  about  the  state  of  the  sender,  we  have  the  basis  for  communication. 

One  difficulty  in  designing  C4  systems  to  support  commanders  is  that  a 
commander  who  must  acquire  more  knowledge  about  his  or  her  decision  space 
must  rely  on  secondhand  reports  from  a  variety  of  sources  over  which  he  or  she 
has  no  direct  control.  While  those  sources  will  genuinely  try  very  hard  to 
anticipate  and  respond  to  commanders'  needs,  any  architecture  that  attempts  to 
fully  satisfy  the  informational  requirements  of  all  commanders  in  a  given  region 
with  the  same  reports,  whether  or  not  they  are  broadcast,  is  bound  to  fail.  Also, 
an  architecture  that  does  not  ensure  direct  feedback  between  commanders  and 
their  sources  of  information,  with  guaranteed  timely  and  relevant  responses  to 
their  requests  for  data,  will  not  be  sufficiently  adaptive. 

Any  C4  architecture,  then,  has  at  least  four  informational  needs,  which  are 
summarized  in  the  left  half  of  Table  3.1.  First,  it  must  provide  support  for 
operations,  consisting  of  data  that  are  suitably  timely  for  operations  and  that  are 
accurate,  sufficient,  and  understandable.  Second,  it  must  be  fully  interoperable 
with  joint  forces,  combined  forces,  and  civilian  agencies,  where  necessary.  Third, 


*For  a  discussion  of  this  subject,  see  Cunningham  and  Taylor  (1994)  and  Cunningham,  Taylor,  et 
al.  (1993). 

^ Decision  space  refers  to  all  subject  matter  that  is  related  to  a  set  of  decisions  for  which  a 
decisionmaker  is  partially  or  totally  responsible  and  to  the  set  of  all  possible  decisions  the 
decisionmaker  may  make. 
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it  must  provide  comprehensive  data,  including  all  categories  needed  to  support 
decisionmaking  and  operational  planning*  Fourth,  it  must  be  responsive  to 
commanders'  tasking  and  retasking  to  meet  their  changing  needs. 


Physical  Needs 

A  C4  subarchitecture3  must  also  meet  the  six  physical  needs  summarized  on  the 
right  side  of  Table  3.1.  First,  it  must  be  available  when  needed,  so  the  relays  and 
terminals  and  their  connections  must  have  the  same  deployment  priority  as  the 
supported  forces.  Second,  it  must  be  self-sustaining  (i.e.,  able  to  operate 
continuously  in  a  region  without  infrastructure).  Third,  it  must  be  as  mobile 
within  the  region  as  the  forces  it  supports.  The  terminals  connected  to  the 
architecture  must  connect  the  users  to  their  sources  of  data  at  all  times  and 
without  the  need  to  stop,  set  up,  and  make  connections.  Fourth,  it  must  be 
adaptable,  which  means  it  must  instantaneously,  or  very  rapidly,  accommodate 
all  necessary  changes  (e.g.,  adapt  to  changes  in  the  environment,  add  new  users 
and  purge  unwanted  ones,  and  conform  to  changes  in  plans,  the  conflict 
situation,  and  the  mission).  Fifth,  it  must  be  reliable  and  robust  (i.e.,  it  must  have 
redundancy,  be  self-restoring,  offer  only  minimum  signatures,  provide 
communications  security,  and  be  resistant  to  jamming).  Sixth,  it  must  provide 
support  to,  and  be  supported  by,  the  CSS  spectrum. 

Finally,  affordability  is  one  of  the  most  important  attributes  of  an  architecture, 
because  cost  is  often  the  determining  factor  of  the  deployed  capability. 

Table  3.1 

Informational  and  Physical  Needs  of  C4  Subarchitectures 


Informational  Needs 

Physical  Needs 

Supportive  of  operations 

Available 

Interoperable,  joint  and  combined 

Self-sustaining 

Comprehensive  data 

Mobile 

Responsive  to  commanders'  needs 

Adaptable 

Reliable  and  robust 

Supportable  and  supporting 

3A  distinction  is  made  between  the  meta-architecture  that  includes  all  DoD  system  networks 
and  the  subordinate  architectures  referred  to  in  this  report,  which  are  called  C4  subarchitectures. 
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Ranges  of  Quantifiable  Measures  for  Informational  and 
Physical  Needs 

Although  this  study  did  not  address  in  detail  the  process  involved  in  actually 
measuring  the  informational  and  physical  needs  of  C4  subarchitectures,  it  did 
consider  a  range  of  possible  dimensions  for  them.  The  measures  discussed  below 
are  not  intended  to  be  comprehensive,  nor  are  they  necessarily  the  best  ones. 

Our  goal  was  to  describe  an  approach  that  might  be  further  developed  into  a 
useful  methodology  for  performing  cost-benefit  and  trade-off  analyses. 

Ranges  of  Measures  for  Informational  Needs 

Although  this  study  dealt  primarily  with  qualitative  criteria,  it  also  considered 
that  each  criterion  has  an  expected  range  with  measurable  dimensions. 
Measurable  dimensions  for  "Supportive  of  operations"  are  timeliness,  accuracy, 
and  adequacy  of  data  to  enable  planning  and  decisionmaking.  Since  only  users 
can  determine  whether  or  not  the  data  they  received  met  their  requirements,  and 
only  after  the  data  were  received,  it  is  necessary  to  establish  a  range  of  accepted 
values  beforehand.  Consequently,  the  measures  are  the  difference  between  the 
preestablished  criteria  for  timeliness,  accuracy,  and  sufficiency  for  each  given 
situation.  There  is  already  Army-accepted  precedent  for  this  in  the  commander's 
situation  briefings,  his  Prioritized  Intelligence  Requirements,  and  his  Critical 
Information  Requirements  procedures. 

Measures  for  "Interoperable,  joint,  and  combined"  depend  on  the  degree  to 
which  equipment  standards  and  operating  protocols  are  interoperable,  and  the 
degree  to  which  this  is  achieved  can  be  measured  in  terms  of  the  percentage  of  a 
force,  unit,  or  system  level  that  is  equipped  with  interoperable  equipment  using 
suitable  standards  and  operating  protocols. 

"Comprehensive  data"  refers  to  the  understandability  and  usefulness  of  the  data 
carried  by  the  architecture  and  can  be  measured  much  like  support  of 
operations — the  user  establishes  beforehand  a  range  of  accepted  values,  and  the 
measures  are  given  in  percentages  for  the  difference  between  the  preestablished 
criteria  (e.g.,  for  each  functional  domain,  if  desired)  and  the  results  for  each 
situation. 

Although,  in  one  way  or  another,  all  of  the  above  categories  help  determine 
whether  an  architecture  is  "Responsive  to  commanders'  needs,"  we  refer  here  to 
his  ability  to  use  the  architecture  to  task  and  retask  sources  of  data  to  meet 
changing  requirements.  In  this  case,  the  measure  is  time,  and  the  commander 
must  preestablish  the  criteria  for  responsiveness. 
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Ranges  of  Measures  for  Physical  Needs 

Under  physical  needs,  "Available"  has  a  time  dimension  that  ranges  from  having 
the  C4  equipment  arrive  in  the  region  either  at  the  same  time  as  the  other  early- 
entry  systems  do  (e.g,,  mechanized  infantry,  fire  support)  to  having  it  arrive  at  a 
later  time  (e.g.,  when  the  main  forces  arrive  or  just  prior  to  the  time  they  engage 
in  combat). 

"Deployability,"  which  relates  to  availability  in  the  region,  can  have  several 
dimensions.  Although  this  study  does  not  deal  with  unit-specific  deployability 
trade-offs,  the  Time  Planned  Force  Development  and  Deployment  List  (TPFDDL) 
must  be  very  sensitive  to  when  C4  systems  are  deployed.  For  example,  early- 
entry  forces  clearly  need  C4  systems  that  can  be  deployed  with  a  minimum  of 
airlift  and  sealift.  However,  it  is  not  dear  that  separate  C4  equipment  used  by 
heavy  divisions  needs  the  same  degree  of  compactness  as  that  used  by  lighter 
forces  if  the  heavy  ones  have  sufficient  lift.  If,  on  the  one  hand,  heavy  division 
equipment  is  to  be  deployed  by  sealift  or  can  be  prepositioned  in  specific 
theaters,  size  and  weight  limitations  may  not  be  as  restrictive  as  they  are  for  light 
or  early-entry  forces.  If,  on  the  other  hand,  both  heavy  and  light  forces  depend 
mainly  on  airlift  and  have  their  C4  systems  integrated  in  all  major  items  of 
equipment  so  there  is  little  additional  requirement  for  lift,  the  time  to  deploy 
would  be  greatly  minimized. 

"Self-sustaining"  also  has  measurable  dimensions.  For  example,  there  are 
acceptable  times  when  systems  may  be  out  of  operation,  including  downtime 
planned  to  accommodate  communication  satellite  or  aerial  platform  orbits.  Also, 
the  number  of  platforms  and  systems  required  to  maintain  continuous, 
uninterrupted  operations  is  another  measure.  This  would  include  the  number 
and  types  of  alternate  C4  systems  required  for  backup. 

How  "Mobile"  C4  systems  are  can  be  quantified  according  to  operational  phases 
they  are  supporting  (e.g.,  attack,  counterattack,  position  or  mobile  defense),  as 
well  as  by  the  echelon  assignment.  During  ODS,  the  Army  used  tracked  mobile 
C2  vehicles  (C2Vs),  but  they  were  unable  to  keep  up  with  the  faster  maneuver 
units,  not  because  the  vehicles  themselves  were  too  slow,  but  because  the  time 
required  to  connect  to  the  much  slower-moving  MSE  grid  was  too  long. 
Therefore,  while  the  mobility  requirement  could  be  linked  with  the  mobility  rate 
of  the  maneuver  units  (e.g.,  presently,  an  average  speed  of  35  km  per  hour),  the 
time  it  takes  to  maintain  connectivity  networks  (i.e.,  the  setting  up  and  tearing 
down  of  antennas,  the  connecting  of  power  units  and  other  equipment,  and  the 
establishing  of  connections  to  the  C4  subarchitecture  and  its  meta-architecture) 
must  also  be  considered. 
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Measuring  how  "Adaptable"  a  C4  system  is  involves  both  the  time  and  data- 
volume  dimensions.  For  example,  a  network  of  users  (i.e.,  report  recipients)  and 
data  sources  will  have  a  characteristic  timeliness  for  each  of  the  several  missions 
it  supports.  The  adaptability  of  a  C4  system  will  also  involve  how  fast  a  change 
can  be  accommodated,  including  changes  in  the  user  group,  the  data  sources,  or 
the  mission  assignment  of  all  three  components.  Another  adaptability  measure  is 
the  volume  of  reports  that  must  be  generated  for  each  combination  of  network 
factors. 

"Reliable  and  robust"  measures  how  well  the  C4  system  can  handle  shocks, 
degradations,  losses,  and  additions  to  the  physical  system.  Examples  of  shocks 
to  the  physical  system  are  losses  due  to  enemy  action  or  natural  disasters. 
Reliability  is  often  measured  in  two  ways:  (1)  as  the  reliability  of  a  design,  and 
(2)  as  a  resulting  operational  readiness  rate.  The  latter  can  be  influenced  by  the 
number  of  backup  modes  built  into  the  design  or  the  number  of  duplicate 
systems  included  in  the  TPFDDL. 

"Supportable  and  supporting"  can  be  measured  in  several  ways.  "Supportable," 
for  example,  describes  whether  or  how  well  the  C4  system  can  be  supported  by 
the  armed  forces  in  terms  of  manpower,  training,  organization,  maintainability, 
resource  requirements,  etc.,  as  part  of  the  overall  force.  The  supporting  attribute 
measures  how  well  the  architecture  supports  the  users  in  terms  of  timeliness  of 
reports  delivered,  volume  of  reports,  and  overall  responsiveness  to  data  requests. 

There  are  perhaps  other  categories  and  criteria  for  measuring  them  (e.g., 
maintaining  continuity  of  operations  with  multigenerational  systems  as  complete 
or  major  components  of  old  systems  are  retired  and  new  ones  are  fielded); 
however,  we  did  not  attempt  to  examine  this  aspect  of  the  problem,  because  our 
focus  in  this  concept-formulation  study  is  on  the  overall  compositions  of 
architectures.  The  transition  from  today's  C4  architecture  to  any  new 
architecture  will  always  result  in  a  performance  degradation  from  that  predicted 
for  the  idealized  new  architecture,  because  the  C4  architecture  is  so  large  that 
some  elements  are  expected  to  be  in  transition,  so  the  idealized  architecture  is 
never  achieved.  But  this  fact  does  not  mitigate  the  importance  of  top-level 
comparisons  of  the  characteristics  of  future  C4  architectures  nor  the  importance 
of  understanding  the  transition  issues. 
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4.  Analysis  of  the  Army's  Current  and 
Planned  C4  Subarchitecture 


In  this  section,  we  analyze  the  Army's  current  and  planned  C4  subarchitectures 
to  determine  how  well  they  stack  up  against  the  informational  and  physical 
needs  discussed  in  Section  3  and  the  operational  objectives  that  underlie  those 
needs.  Following  a  brief  discussion  of  a  subarchitecture's  basic  components,  the 
section  examines  the  Army's  current  C4  subarchitecture,  evaluates  it  against  the 
informational  and  physical  needs,  and  then  discusses  how  the  planned 
subarchitecture  will  address  any  shortcomings. 


Basic  Components  of  a  C4  Subarchitecture 

All  C4  subarchitectures  have  three  basic  components:  (1)  Information  sources, 
such  as  databases,  sensors  that  collect  new  data,  and  operational  unite  that 
provide  inputs  based  on  their  status  and  performance;  (2)  collection,  production, 
and  dissemination  facilities  (CPDFs),1  which  convert  the  raw  data  into  usable 
products;  and  (3)  users,  such  as  commanders  and  their  staffs,  who  give  or  receive 
tasking  orders,  store  data,  or  transmit  diem  to  other  operational  forces.  These 
components  may  be  connected  in  various  ways,  and  the  connections  themselves 
form  an  independent  part  of  each  subarchitecture.  In  this  sense,  we  do  not 
present  complete  architectures  in  this  discussion,  only  their  subsets.  But  how  the 
subarchitectures  are  connected  has  an  impact  on  how  well  they  meet  the 
informational  and  physical  needs  outlined  in  Section  3. 


The  Army's  Current  C4  Subarehitecture 

The  Army's  current  C4  subarchitecture,  which  is  illustrated  in  Figure  4.1,  was 
based  on  the  C2  Mini-Functional  Area  Analysis  Study  and  the  MILSATCOM 
Architecture  Study  (U.S.  Army  Signal  Center,  1993).  This  architecture  is  based  on 
the  philosophy  that  reports  from  all,  or  as  many  as  possible,  of  the  numerous 
inter-  and  intraregional  systems  should  go  directly  to  the  commanders  or  their 
staffs.  While  the  rationale  for  this  philosophy  is  to  ensure  that  commanders 


^CPDF  is  a  term  we  coined  to  describe  a  central  place  where  all  source  collection,  production, 
and  dissemination  operations  are  performed  and  standard  and  special  types  of  reports  are  prepared 
and  disseminated. 
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receive  timely  and  accurate  data,  the  large  and  ever-increasing  number  of  diverse 
systems  is  impractical  to  accommodate.  They  operate  on  different  frequency 
bands  and  require  unique  terminals,  which  are  continually  changing,  resulting  in 
a  CP  that  is  large,  cumbersome,  operator-intensive,  expensive,  and  easy  to  detect 
by  an  adversary. 

Presently,  there  are  several  different  types  of  data-collection  and  report- 
production  facilities — some  outside  of  an  operational  region  (e.g.,  in  the 
CONUS),  and  many  set  up  within  a  region.  Each  is  responsible  for,  and 
optimized  to  support,  a  particular  functional  domain  (e.g.,  intelligence, 
maneuver,  fire  support,  air  defense,  and  CSS);  thus,  they  differ  considerably 
according  to  their  subarchitecture  designs,  component  systems,  standards,  and 
protocols. 

Figure  4.2  provides  a  subset  view  of  this  architecture,  showing  its  multiple 
subarchitectures,  each  of  which  feeds  data  on  its  particular  topic  to  the  tactical 
operations  center  (TOC)  in  a  CP.  Thus,  there  is  one  information  production  and 
dissemination  facility  for  CSS,  another  for  intelligence,  another  for  maneuver, 
and  yet  another  for  other  kinds  of  data  to  help  promote  situation  awareness. 


Rivet  Joint 


Dlv  Broadcast  Nat  Data 


GPS/weather 


NOTE:  The  more  detailed  subarchitectures  for  aviation,  MCS,  TACFIRE,  EPLRS,  and  many  other 
lower-echelon  systems  are  not  represented  in  this  figure.  See  abbreviations  list  for  definitions  of 
acronyms. 


Figure  4.1 — The  Army's  Current  C4  Subarchitecture 
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Figure  4.2— Schematic  of  the  Army's  C4  Subarchitecture  Configuration 


The  feedback  loops  required  to  redirect  collection  planning  and  collection 
management  efforts  are  organized  according  to  specific  functional  domains 
(Combined  Arms  Control,  1992a).  For  example,  in  the  intelligence  production 
center  model,  these  loops  were  designed  for  specific  system  operations  (e.g., 
signal,  image,  and  human  intelligence;  weather;  and  topography),  as  well  as  for 
position  location  and  fire  support.  As  a  result,  this  architecture  is  difficult  to 
control,  and  efforts  to  integrate  operations  (either  horizontally  or  vertically)  and 
to  synchronize  them  may  not  be  sufficiently  timely  or  efficient. 

The  requirements  for  equipment  and  expertise  to  integrate  and  manage  the  large 
amounts  of  diverse  data  at  a  TOC  and  other  CPs  are  massive,  which  increases  the 
need  for  skilled  operators  there  or  further  burdens  the  staff  and  limits  unit 
mobility.  The  data  integration  process  itself,  notwithstanding  the  fact  that  new 
technologies  can  greatly  speed  up  the  process,  detracts  from  the  commander's 
ability  to  perform  C2. 


The  Army's  Evolving  C4  Subarchitecture 

The  Army  is  evolving  its  current  architecture  by  integrating  it  with  the  Army 
Tactical  Command  and  Control  System  and  further  with  the  Army  Global 
Command  and  Control  System.  In  this  evolving  architecture  (shown  in  Figure 
4.3),  the  CPs  and  the  C2Vs  receive  data  from  a  variety  of  CPDFs,  each  devoted  to 
a  particular  function  (e.g.,  CSS,  intelligence,  and  other  situation  awareness 
reports),  as  well  as  from  a  number  of  sensors.  The  data  products  are  sent  to  users 
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in  the  region  primarily  through  terrestrial  MSE  links.  The  architecture  would  be 
augmented  by  satellite  communication,  and  although  there  are  plans  for  some 
reports  to  be  broadcast  to  users  and  some  space-based  systems  may  be  used  for 
that,  the  plans  call  for  doing  so  only  for  specific  kinds  of  data  along  certain 
functional  domain  lines  (e.g.,  warnings),  rather  than  for  all  kinds  of  data. 

Notwithstanding  these  incremental  improvements,  this  subarchitecture  is 
unwieldy  and  difficult  to  control,  primarily  because  various  kinds  of  data  and 
formats  from  different  data  sources  all  converge  at  different  times  and  at  a  single 
place  for  the  commander  to  integrate  and  try  to  make  sense  of.  This  means  that  a 
C2V  for  the  commander  and  his  staff  would  probably  require  a  multitude  of 
different  receivers  and  antennas  to  receive  reports  from  all  the  different  CPDFs 
and  sensors.  This  requirement  for  a  large  number  of  transceivers  to  operate  on 
many  radio  frequencies  and  for  the  associated  antennas  would  adversely  affect 
the  CP's  survivability  and  the  C2Vs'  mobility.  In  addition,  this  subarchitecture  is 
still  divided  into  physically  separated  processing  centers  set  up  according  to,  and 
optimized  for,  the  functional  domains  (e.g.,  CSS,  intelligence,  fire  support)  and 
their  sub-subarchitectures.  Finally,  deploying  the  large  amounts  of  diversified 
equipment  required  at  each  CP  would  involve  many  operators  and  high  costs. 

An  alternative  configuration  that  might  overcome  many  of  the  built-in 
difficulties  from  functional  domain  rigidity  would  be  to  organize  several  more  or 
less  identical  processing  centers  (such  as  CPDFs)  that  would  produce  and 
disseminate  reports  across  all  the  functional  domains  or  specified  groups  of 
them.  Although  they  might  be  physically  separated,  they  could  be  virtually 
centralized  with  data  links. 


Several  CPDFs 
in  the  region 


/  t  V 


Figure  4.3— Army's  Evolving  C4  Subarchitecture 
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Evaluating  the  Army's  Current  and  Evolving  C4 
Subarchitectures  Against  Informational  and  Physical 
Needs 

Tables  4.1  and  4.2  present  the  apparent  shortfalls  in  informational  and  physical 
needs  of  the  Army's  current  and  evolving  C4  subarchitectures.  The  fact  that 
these  apparent  shortfalls  exist  does  not  imply  that  this  subarchitecture  has  no 
positive  features. 

In  the  following  section s,  we  examine  some  elements  of  a  C2  architecture  that  can 
help  it  overcome  the  shortfalls  described  above:  CtC  communications,  SIS,  and 
CFO. 


Table  4.1 

Apparent  Shortfalls  in  Informational  Needs  of  Army's  Current  and 
Evolving  Subarchitecture 


Informational  Needs 

Apparent  Shortfalls 

Supportive  of  operations 

Interoperable 

Comprehensive 

Responsive  to 
commanders*  needs 

Data  lack  timeliness,  accuracy,  and  sufficiency  for 
synchronizing  operations 

Limited  connectivity  with  joint  and  combined  forces 
or  civilian  agencies 

Connected  to  a  large  variety  of  data  sources  that  use 
dissimilar  reports,  formats,  and  procedures;  requires 
many  skilled  operators  in  the  region 

Mostly  indirect  connections  to  major  sources  of  data; 
limited  tasking  authority 

Table  4.2 

Apparent  Shortfalls  in  Physical  Needs  of  Army's  Current  and 

Evolving  Subarchitecture 

Physical  Needs 

Apparent  Shortfalls 

Available 

Self-sustaining 

Mobile 

Adaptable 

Reliable  and  robust 
Supportable  and  supporting 

Must  deploy  large  amounts  of  dissimilar  equipment 
Limited  capability  to  operate  without  available3 
infrastructure  in  the  region 

Requires  setting  up,  tearing  down,  and  moving  a 
large  variety  of  equipment  to  keep  pace  with  mobile 
forces 

Difficult  to  reconfigure  systems  to  meet  changes  after 
systems  and  units  are  deployed 

Large  physical  and  electromagnetic  signatures 

Large  quantity  of  dissimilar  equipment,  which 
produces  numerous  line  items  and  supply  and 
training  costs 

aBy  available,  we  mean  here  that  communications  facilities  for  connecting  Army  systems  are 
physically  present  in  a  region  and  that  no  political,  commercial,  or  other  restrictions  limit  their 
accessibility  to  U.S.  forces. 
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5.  Computer-to-Computer 
Communications 


As  revealed  above,  one  major  drawback  to  C2  efficiency  is  that  data  transfers 
between  computers  currently  take  place  over  architectures  that  are  not  optimized 
for  such  transfers.  In  the  past,  except  for  Air  Defense  subarchitectures,  all 
communications  required  the  direct  action  of  operators  at  both  the  sending  and 
receiving  ends.  Now,  many  data  exchanges  are  automated,  taking  place  much 
faster  than  humans  can  assimilate  or  act  upon.  This  section  examines  such  CtC 
exchanges,  looking  first  at  when  they  should  be  used  and  then  presenting  some 
potential  military  applications  for  them. 


Using  CtC  Exchanges 

When  CtC  exchanges  are  used,  they  usually  occur  in  situations  structured  to 
accommodate  person-to-person  (PtP)  communications.  One  example  that  shows 
the  inefficiency  of  this  arrangement  is  Scud-busting.  This  process  in  ODS 
involved  (1)  employing  sensors  to  search  for,  identify,  locate,  and  acquire  a 
transporter-erector-launcher;  (2)  transfering  essential  data  to  a  weapon-control 
facility;  and  (3)  observing  whether  or  not  the  target  was  destroyed.  All  of  these 
actions  should  have  been  accomplished  within  an  extremely  brief  period  of  time. 
Without  the  appropriate  architecture,  data  exchanges  for  such  exceedingly  time- 
limited  operations  will  not  be  timely. 

CtC  should  not  use  architectures  designed  for  PtP  for  the  following  reasons: 

1.  PtP  architectures  are  technically  suboptimal  for  CtC  uses.  CtC  networks  are 
used  mainly  to  exchange  digital  data  to  control  machines,  not  to  exchange 
imagery,  voice,  or  text.  However,  all  three  formats  can  be  sent  as  digital 
data. 

2.  Most  CtC  nodes  have  no  reason  to  be  situated  at  CPs  if  they  are  not  directly 
involved  in  supporting  human  communications  or  monitoring  the  status  of 
machines.  Typically,  these  computers  are  integrated  into  other  kinds  of 
machines,  such  as  sensors,  automatic  processors,  and  space  and  airborne 
platforms  (including  manned  orbiting  and  unmanned  aerial  vehicles 
[UAVs]). 
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3,  If  operators  intervene  in  the  data  streams  of  CtC  architectures,  they  can  delay 
or  disrupt  them.  In  addition,  if  CtC  channels  are  available  to  people,  they 
may,  when  communications  networks  are  heavily  loaded,  decide  to  preempt 
those  channels  for  PtP  and  computer-to-person  uses.  Such  disruption  of  data 
flows  can  adversely  affect  the  CFs  operations  or  those  of  other  commands. 

4.  Requiring  CtC  linkages  to  conform  to  PtP  architectures  that  follow  command 
hierarchical  paths  rather  than  those  designed  for  efficient  machine  exchanges 
increases  the  number  of  nodes  and  data  translation  buffers  required  to 
achieve  system  interoperability.  The  best  type  of  architecture  for  CtC  is  one 
that  connects  machine  nodes  directly.  Machines  can  automatically  exchange 
large  volumes  of  data  with  other  machines  at  much  faster  rates  than  humans 
can  assimilate  or  act  on.^  Machines  can  also  process  the  data,  filtering  and 
abstracting  according  to  human  instructions.  Processed  data  can  then  be 
transferred  to  humans  to  make  decisions  or  to  set  new  threshold  levels  for 
desired  actions. 


Current  and  Evolving  CtC  Military  Applications 

CtC  exchanges,  especially  digital  data  transactions,  are  definitely  on  the  rise  and 
are  expected  to  increase.^  Here  are  some  current  and  evolving  examples  for 
military  applications: 

•  On-board  data  processing 

•  Automated  UAV  operations 

•  Automated  data  relays  and  switches 

•  Integrated  GPS  receivers  connected  to  control  centers  by  line-of-sight  (LOS) 
satellite  relays 

•  Automated  logistics  tracking  and  inventorying 

•  Teleoperated  mines  and  unattended  data-linked  ground  sensors. 

The  Services  should  consider  designing  data  network  architectures  for  CtC  and 
PtP  uses  that  are  independent  of  command  hierarchies  and  not  requiring  CtC 
exchanges  to  conform  to  PtP  command-level  hierarchies  (e.g.,  corps  to  division  to 


^This  means  that  standards  and  profiles  to  achieve  system  interoperability  among  machines  are 
just  as  necessary  for  service  interoperability  among  commands  and  their  forces. 

2As  noted  earlier,  subsequent  to  this  study,  the  Army  initiated  a  major  effort  to  digitize  the 
battlefield.  This  effort  is  being  managed  by  the  Army  Digitization  Office  (ADO)  as  part  of  the  Force 
XXI  activities.  Three  major  exercises  are  included  in  the  plan:  a  digitized  Battalion  Task  Force  XXI 
(94);  a  digitized  Brigade  Task  Force  XXI  (97);  and  a  digitized  Division  XXI  (99).  The  digitization  of  the 
battlefield  initiative  is  one  of  three  thrusts  the  Army  is  pursuing  to  achieve  Force  XXI. 
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brigade  to  battalion).  This  will  require  characterizing  and  analyzing  the  expected 
volume  and  rates  of  CtC  and  PtP  data  exchanges  for  future  scenarios  to 
determine  system  hardware,  software,  interfaces,  and  other  requirements.3 
Then,  analysis  will  be  needed  to  determine  the  appropriate  balance  in  the  total  C4 
architecture  between  those  resources  that  are  devoted  to  reports  exchanged  via 
imagery,  text,  and  voice  and  those  that  are  devoted  to  digital  data  exchanges 
between  computers  and  other  machines. 

CSS  is  one  example  that  could  greatly  benefit  from  an  optimized  CtC 
architecture.  Currently,  CSS  centers  and  units  must  compete  with  the  maneuver 
elements  to  communicate.  We  suggest  it  would  be  better  to  use  small  space 
transponders  installed  in  major  items  of  equipment  (e.g.,  tanks,  armored 
personnel  carriers,  howitzers,  missile  launchers,  air  defense  weapons,  and 
aircraft).  Transponders  are  especially  appropriate  for  this  purpose,  and  they  can 
be  connected  to  small  space-based  terminals  by  adapting  evolving  technologies 
for  hand-held  transceivers  for  personal  communications  for  CtC  exchanges.  By 
embedding  transponders  in  major  items  of  equipment  and  connecting  them  to 
on-board  sensors,  CSS-relevant  data  about  the  status  of  equipment  and 
consumption  of  key  commodities  (ammunition  and  petroleum,  oil,  and 
lubricants  [POL])  could  be  automatically  monitored  and  reported.  Data  from  the 
transponders  could  be  automatically  sent  to  CPDFs  via  low-data-rate  satellites 
(e.g.,  INMARSAT)  in  low  and  medium  earth  orbits.  There  the  data  would  be 
aggregated,  analyzed,  and  sent  to  operators  at  various  command  levels  and  to 
the  sustaining  base  in  the  form  of  reports  via  a  PtP  architecture.  These  data  could 
also  be  used  to  update  CS  and  CSS  databases  and  to  inform  various  action 
centers  and  commands/ agencies  when  thresholds — set  by  operator  personnel 
and  continually  monitored  and  adjusted  to  conform  to  the  operation's 
dynamics — are  reached.  This  will  prove  very  valuable  to  depots  and  ports 
concerned  with  planeloads  and  shiploads,  to  armies  and  corps  concerned  with 
major  supply  areas  and  shipping  container  loads,  and  to  divisions  and  brigades 


^Consider  a  typical  scenario  of  a  conflict  situation  in  which,  initially,  combat  forces  are  deployed 
in  a  region  for  a  relatively  brief  time,  followed  by  an  extended  posthostilities  period  during  which 
U.S.  force  elements  are  engaged  in  security  assistance,  civil  affairs,  humanitarian  assistance,  medical 
support,  and  other  similar  noncombat,  peacekeeping  activities,  occasioned  by  periodic  unrest  brought 
about  by  sporadic  violent  outbreaks  of  terrorism.  The  requirements  for  CSS  data  exchanges  during 
the  times  of  relative  calm  can  easily  dominate  those  needed  for  combat  operations,  both  at  the 
beginning  of  the  campaign  and  during  any  sudden  unexpected  outbreaks  of  violence.  However,  if 
the  architecture  is  designed  primarily  to  support  combat  operations,  with  connections  to  specialized 
data  sources,  it  could  be  too  inflexible  to  rapidly  shift  to  the  new  dynamic  requirements,  and  its 
adaptation  might  be  clumsy  and  possibly  incur  unacceptable  delays.  Consequently,  the  objective 
architecture  should  be  designed  to  readily  shift,  all  or  in  part,  to  support  simultaneously  either 
combat  or  noncombat  operations  or  both  by  readily  and  seamlessly  adding  and  deleting  providers  of 
data  and  new  users.  Designing  the  architecture  in  a  very  open  way  and  from  a  top-down  perspective 
would  provide  the  greatest  flexibility,  thus  enabling  dramatic  swings  to  be  accommodated.  For  this 
reason,  architectures  that  are  based  primarily  on  space-based  capabilities  that  can  instantly  shift  in 
any  direction  appear  to  offer  major  advantages  over  ground-based  ones. 
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concerned  with  supply  points  down  to  truckloads.  There  are  obviously 
commercial  applications  as  well. 

By  conceptualizing  and  describing  new  applications  for  (^related  technologies 
that  could  have  both  commercial  and  military  uses,  the  Army  also  has  an 
opportunity  to  identify  resources  from  industry  and  elsewhere  outside  the  Army. 
In  the  past,  the  Services  developed  new  technologies  that  were  later  transferred 
to  commercial  applications  as  spin-offs.  We  propose  that  in  the  future,  the 
Services  look  ahead  to  where  new  technologies  are  going  and  identify  ways  both 
the  Services  and  commercial  entities  can  benefit  from  those  technologies. 

One  example  would  be  to  develop  mobile  crisis  control  action  centers  for  use  by 
the  National  Guard,  the  Federal  Emergency  Management  Agency,  and  the  U.S. 
Department  of  Forestry  for  combating  large  fires,  as  well  as  for  use  by  states  and 
large  cities  where  natural  disasters  and  civil  disorder  may  occur.  This  kind  of 
equipment  might  also  be  useful  to  many  countries  for  dealing  with  civil  strife 
and  supporting  disaster-relief  efforts. 

Other  specialized  groups  also  depend  on  mobile  C2Vs  and  accurate  and  timely 
reports  for  their  operations  when  they  are  in  remote  areas.  Three  examples  are 
environmental  survey,  oil  exploration,  and  fire-fighting  teams.  The  Army  may 
wish  to  help  promote  the  aims  of  specialized  groups  by  collaborating  with  them 
and  with  industry,  pooling  concepts  and  designs,  and  sharing  test  data.  The 
Army  also  stands  to  benefit  from  this  kind  of  interaction  with  industry 
representatives  by  encouraging  and  gaining  support  from  those  groups  that 
require  advanced  systems  and  specialized  software,  thus  lowering  production 
costs  and  enhancing  designs  for  both  military  and  nonmilitary  applications. 

Another  idea  would  be  to  encourage  the  television  industry  to  develop  highly 
mobile  C2Vs  connected  to  an  overhead  relay  and  switch  for  reporting  television 
and  radio  newscasts  and  other  related  communications  from  regions  with  limited 
or  no  available  communications  infrastructure.  The  television  industry  is  already 
experimenting  with  a  similar  capability  using  ground-based  communications 
augmented  with  commercial  satellite  links.  One  illustration  of  this  is  NASA's 
Advanced  Communications  Technology  Satellite  (ACTS)  demonstration 
program. 

ACTS  is  an  experimental  satellite  platform  being  used  for  both  commercial  and 
military  applications.  The  Army  Space  Command  has  already  demonstrated  its 
use  in  providing  voice,  high-data-rate  video,  and  other  data  transmissions 
(including  video  conferencing  between  tactical  units  in  the  field)  and  in  sending 
weather,  intelligence,  and  other  operational  data.  Experiments  have  been 
conducted  with  divisions  at  Ft.  Hood,  Texas,  and  Ft.  Irwin,  California — where 


23 


the  NTC  is  located — that  involve  sending  unit  position  location  data  and 
operational  plans. 

ACTS  is  also  being  used  for  financial  data  transactions  between  the  Huntington 
Bank  in  Columbus,  Ohio,  and  one  of  its  check-processing  centers  in  Parma,  Ohio, 
to  demonstrate  its  capability  for  providing  a  backup  data  link  if  landlines  are 
interrupted. 

Another  particularly  interesting  ACTS  experiment  that  has  great  potential  for 
both  military  and  commercial  mobile  ground  and  airborne  applications  is  its 
demonstrated  capability  for  placing  telephone  calls  between  a  ground  station 
and  a  commercial  jet  traveling  at  high  speed.  Electronically  steered  antenna 
beams  on  the  ACTS  satellite  have  been  used  to  track  the  aircraft  while  in  flight  to 
keep  it  in  constant  communications  with  the  ground  station. 

Yet  another  example  is  to  consider  what  technologies  and  applications  for  them 
might  follow  handheld  communications  satellite  transceivers,  which  are  now 
being  rapidly  developed  and  made  smaller  and  more  capable.  Although  the 
number  of  people  in  the  world  who  might  wish  to  communicate  via  satellite 
telephony  could  eventually  be  on  the  order  of  one  billion,  the  types  and 
quantities  of  equipment  many  of  us  may  want  to  keep  track  of  could  be  much 
greater.  Possible  Army  and  commercial  applications  are  for  monitoring  the 
location,  status,  and  performance  of  equipment.  This  could  be  accomplished  by 
installing  small,  low-cost  transponders  in  major  items  of  equipment.  The 
transponders  would  be  connected  to  a  variety  of  on-board  sensors  and  would 
periodically  send  their  data  via  space-based  terminals. 

The  trucking  industry  has  already  begun  extensively  using  transponders  to 
monitor  and  automatically  report  to  central  points  the  location  of  each  vehicle  in 
its  fleet  and  such  other  events  as  speeding,  the  arrival  or  nonarrival  of  trucks  at 
designated  points,  and  load  weights  over  specified  limits.  Presumably,  the  Army 
could  also  benefit  from  this  technology,  beyond  just  applications  for  CSS,  by 
employing  sensors  and  transponders  in  military  vehicles  and  weapons,  which 
would  be  queried  periodically  to  send  operational  status  and  historical  data  to 
centers  through  space-based  links.  One  way  the  Army  might  help  promote  this 
capability  is  to  conduct  limited  and,  therefore,  low-cost  feasibility 
demonstrations  using  transponders  from  commercial  fleet  equipment  adapted  to 
military  applications.  Some  examples  of  operational  data  are  unit  locations  in 
forward,  rear,  or  flank  areas  to  designate  the  "front  line"  trace,  rate  of  advance, 
target  areas  being  fired  at,  the  number  and  types  of  rounds  fired  per  weapon, 
firing  rates  by  ammunition  type,  number  and  types  of  rounds  on  hand,  and  crew 
status. 
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Thus,  business  opportunities  apparently  exist  in  these  and  a  number  of  other  C2- 
related  areas.  The  Services  should  not  only  be  ready  to  capitalize  on  military 
applications  but  should  also  help  bring  about  wider  commercial  ones.  Finding 
new  commercial  applications  should  encourage  industry  to  provide  resources  for 
development  and  offer  lower  production  costs  for  military  systems  through 
large-scale  production.  We  are  not  suggesting  the  Services  invest  heavily  in 
developing  new  technologies;  rather,  we  are  suggesting  they  become  actively 
involved  in  partnerships  with  other  potential  users  in  formulating  concepts  for 
both  military  and  commercial  applications  and  in  helping  guide  developments  so 
the  results  can  be  available  to  them  at  an  affordable  cost. 
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6.  Switchboard  in  the  Sky 


Another  C2  deficiency  is  that  the  data  commanders  in  a  region  need  are  often  not 
available  to  them  when  desired.  For  example,  if  commanders'  needs  for  data  are 
responded  to  mainly  after  requests  are  received,  synchronizing  execution  will  be 
difficult,  and  communications  capacity,  which  will  always  experience  high 
demands  during  peak  operational  periods,  may  be  overloaded  when  it  is  most 
needed.  And  since  the  architecture  must  be  engineered  for  peak  demands,  the 
number  of  channels  and  their  carrying  capacity  would  have  to  be  very  large. 
Experience  obtained  from  past  campaigns  indicates  that  the  times  when 
demands  for  information  were  high  were  often  when  communications 
availability  was  low  (House  Armed  Services  Committee,  1992). 

This  section  explores  a  concept  designed  to  remedy  this  deficiency  that  we  call 
the  "switchboard  in  the  sky"  (SIS).  To  do  this,  SIS  proposes  "pushing  forward" 
anticipated  data  in  advance  of  demands.  In  such  a  system,  database  changes  are 
constantly  trickling  in  and  updating  the  commanders'  databases;  as  a  result, 
there  should  be  fewer  demands  (mainly  for  additional  data  and  elaboration),  and 
satisfying  those  demands  should  be  less  hectic.  In  the  remainder  of  this  section, 
we  discuss  the  concept  in  more  detail,  before  turning  to  examine  the  components 
of  such  a  concept  (and  their  functions),  the  postulated  performance  of  the 
concept  against  the  above-mentioned  informational  and  physical  needs,  and 
some  considerations  of  the  concept's  cost  and  performance  trade-offs. 


The  SIS  Concept 

We  define  the  SIS  as  a  decision-support  mechanism  designed  to  provide 
continuous  connectivity  between  the  sustaining  base  and  the  deploying  and 
deployed  units  in  a  region.  Given  the  focus  on  making  all  the  data  needed  by 
commanders  in  a  region  available  to  them  as  they  desire  it,  an  overhead  relay 
and  switch  (the  SIS)  would  be  a  key  feature;  however,  its  importance  lies  in 
helping  to  make  reports  for  planning,  decisionmaking,  and  executing  current 
operations  continuously  available.  To  provide  this  support,  time-critical  reports 
would  be  broadcast  to  all  units  by  the  overhead  relay;  the  remainder  would 
automatically  update  the  local  databases  in  the  CPs'  computer  workstations  with 
current  situation  data  through  optimized  CtC  data  exchanges. 
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This  "pushing  forward"  of  anticipated  data  in  advance  of  demands  has 
important  implications  for  both  system  architecture  and  communications 
channels.  To  help  us  visualize  how  data  might  be  pushed  forward,  temporarily 
held,  and  kept  up  to  date  while  users  pulled  the  data  they  needed  from  it,  we 
originally  used  a  "data  carousel"  as  our  model.  However,  while  this  analogy 
was  useful,  we  have  since  refined  our  thinking  and  now  consider  a  "data  salad 
bar"  analogy  to  be  a  more  accurate  model.  This  is  because  a  carousel  implies 
standard-sized  slots  containing  finite  quantities  organized  according  to 
predetermined  data  domains,  whereas  a  salad  bar  implies  an  infinite  variety  of 
items  to  choose  from  across  all  the  functional  domains.  At  first,  this  distinction 
may  seem  unimportant;  however,  we  believe  it  is  an  essential  part  of  the 
conceptual  process  of  creating  and  analyzing  data  architecture  designs  (e.g.,  in 
helping  to  understand  how  data  should  flow,  where  the  memory  nodes  should 
be  situated,  and  what  their  sizes  should  be). 

For  the  SIS  concept,  we  envision  the  memory  residing  principally  in  four 
locations: 

•  At  the  sustaining  base,  where  large,  complex  historical  and  current  databases 
for  all  the  functional  domains  would  be  maintained  and  kept  up  to  date 

•  At  each  of  the  CPDFs,  where  selected  data  are  pulled  from  the  sustaining 
base,  and  data  are  added  from  current  collection  sources  and  feeder  reports 
from  the  deployed  units 

•  At  the  computer  workstations  in  the  units,  which  are  continually  being 
updated  by  the  CPDFs 

•  At  the  SIS  platform  for  on-board  operations,  which  would  be  monitored  and 
directed  by  the  CPDFs,  for  temporary  "store  and  forward"  exchanges 
between  other  space-based  and  terrestrial  relays  to  ensure  virtual  connection 
continuity,  and  for  temporarily  storing  messages  from  ground  terminals 
(e.g.,  commanders'  requests  for  additional  data  or  data  bursts  from 
embedded  transponders). 

This  fundamentally  new  arrangement  for  memory  storage  would  not  follow  the 
command  hierarchy  of  field  army,  corps,  divisions,  brigades,  and  battalions. 
Instead,  each  of  those  commands  would  obtain  the  data  it  needs  for  its 
operations  from  one  or  more  supporting  CPDFs. 


The  SIS  Architecture 

Figure  6.1  illustrates  the  connection  architecture  conceptualized  for  the  SIS.  Its 
basic  components  are  a  single  CPDF  (although  there  might  be  several  in  a 
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region),  an  overhead  relay  and  switch,  one  or  more  space-based  relays,  and  the 
mobile  C2Vs  in  the  region,  including  both  those  of  the  TOCs  and  those  of  the 
commanders  and  their  staffs.1  The  functions  of  each  of  these  are  described 
below. 

The  Collection,  Production,  and  Dissemination  Facility 

The  CPDFs  would  provide  points  for  receiving  and  disseminating  all  database 
updates  and  other  reports  pertaining  to  regional  activities,  including  those  from 
the  sustaining  base  and  from  units  in  the  field.  Its  databases  would  be 
continuously  updated  with  data  received  from  sensor  platforms,  system  or 
functional-area-specific  processing  centers,  and  other  sources,  such  as  friendly 


Figure  6.1 — Schematic  of  the  Switchboard  in  the  Sky 


1  Although  military  and  commercial  satellites  positioned  to  cover  regions  where  future  conflicts 
and  natural  disasters  might  be  expected  are  a  solution  over  the  long  term,  highly  responsive  "fly¬ 
away"  packages  employing  other  types  of  platforms  (e.g.,  manned  or  unmanned  aircraft  with  the 
same  basic  equipment  for  communications  and  data  exchanges  as  on  satellites)  could  provide 
essential  coverage  for  unexpected  contingencies  in  the  short  term  in  remote  regions  having  little  or  no 
available  communications  infrastructure.  For  reasons  of  efficiency  and  economy,  the  ground 
terminals  would  need  to  work  with  both  the  actual  or  proxy  satellite  systems  regardless,  of  the  type  of . 
platform.  Obviously,  such  fly-away  packages  would  have  major  implications  for  architecture 
designs,  system  interoperability,  and  joint  and  Service  doctrines. 
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units  and  their  databases.  For  example,  reports  automatically  sent  to  the 
sustaining  base  and  the  theater  of  operations  via  the  overhead  relay,  mostly  by 
space-based  relay,  would  include  CSS  data  on  such  commodities  as 
appropriately  aggregated  POL  and  ammunition  consumption  data,  equipment 
and  supply  status,  and  the  current  accurate  location  (with  the  aid  of  GPS)  of  all 
friendly  units.  Reports  received  from  sensor  platforms  (e.g..  Joint  Surveillance 
and  Target  Attack  Radar  System  [JSTARS],  Advanced  Synthetic  Aperture  Radar 
System  [ASARS],  Guardrail  Common  Sensor,  and  the  Ground-Based  Common 
Sensor)  would  be  disseminated  to  units  in  the  region  through  the  overhead  relay 
in  standard  formats  generated  by  the  CPDFs.  Reports  received  from  space-based 
platforms  would  include  weather  and  terrain  imagery,  reconnaissance, 
surveillance,  and  target  acquisition  data. 


The  CPDFs  would  process  these  data  and  then  produce  and  send  reports  using 
standard  formats  to  the  sustaining  base,  the  headquarters  of  interested 
commands  in  the  region,  and  other  centers  through  the  SIS.  These  reports  would 
probably  include  target  identification,  battle  damage,  and  friendly  force 
locations,  as  well  as  intelligence  and  Mission,  Enemy,  Troops  Available,  Terrain- 
Time  (METT-T)  reports.  Standard  formats  might  include  graphics  (e.g., 
photographs,  maps,  map  overlays,  mosaics,  charts,  graphs  supplemented  with 
tables),  written  messages,  and  voice  messages  (such  as  warning  broadcasts). 
Because  the  MI  Relook  Study  determined  that  commanders  prefer  to  receive 
information  in  graphical  format  (Bondanella  et  al.,  1993),  reports  would  be 
provided  principally  as  imagery  with  icons  and  notations,  followed  by 
amplification  when  requested  by  the  recipients. 


To  minimize  the  need  for  additional  tasking  of  collection  resources  and  attendant 
delays  in  information  retrieval,  the  CPDFs  would  constantly  send  updates  of 
these  reports  to  the  SIS  relay.  Time-critical  reports — such  as  warnings  of 
incoming  fires,  target  data,  and  alarms  about  impending  fratricide — would  be 
broadcast  directly  to  those  who  need  to  act  on  the  information  immediately 


(perhaps  temporarily  preempting  whatever  channel  they  may  be  viewing  at  the 


moment).  Other  reports  would  automatically  and  continually  update  the 
databases  in  the  units'  computer  workstations  through  optimized  CtC  data 


exchange  architectures. 


Note  that  the  CPDFs  would  be  equipped  to  interface  with  the  dissimilar  systems 
of  the  various  sources  of  data  (e.g.,  the  different  types  of  collection  systems)  and 
with  the  different  categories  of  users  (e.g..  National  Guard,  coalition  forces,  and 
allied  civilian  agencies,  such  as  police,  fire,  medical,  and  disaster  relief  teams.) 
This  would  eliminate  the  need  for  the  CPs  and  combat  units  to  be  equipped  with 
a  variety  of  different  radios  and  Communications  Electronics  Operating 
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Instructions,  thus  greatly  promoting  interoperability  and  limiting  the  need  for 
specialized  equipment.  In  addition,  the  simultaneous  broadcast  of  reports  in 
graphical  formats  using  universally  joint  standard  icons  and  military  symbols 
would  minimize  the  time  involved  in  producing  reports  in  various  languages 
and  dialects  and  would  speed  comprehension  among  users  no  matter  what  their 
languages. 

The  CPDFs  would  be  located  in  several  places,  in  the  rear  and  forward  areas  of  a 
region  and  in  CONUS.  They  should  be  sufficiently  distant  from  the  conflict  area 
so  they  would  not  be  under  constant  threat  and  would  not  need  to  be  moved 
throughout  a  campaign. 

To  minimize  the  need  for  long-haul,  two-way  communications  and  the  burden 
on  many  bands  and  frequencies,  we  have  envisioned  the  SIS  as  being  located 
essentially  at  some  intermediate  point  between  the  sustaining  base  and  the 
region  of  operations.  However,  for  some  coastal  and  island  regions,  it  might  be 
physically  situated  some  distance  away  and  off-shore,  as  long  as  LOS  contact 
with  terrestrial  terminals  could  be  maintained. 

The  Overhead  Relay  and  Switch 

The  overhead  relay  and  switch  would  broadcast  time-critical  messages  from  the 
CPDFs  using  a  single  band  of  frequencies,  regardless  of  the  type  of  message,  in 
the  same  manner  that  commercial  television  does.  Unit  location,  aided  by  GPS, 
would  be  relayed  by  the  SIS  to  the  CPDFs  and  to  appropriate  data-analysis  and 
weapon-control  centers,  vehicles,  and  patrols.  The  SIS  relay  would  immediately 
broadcast  time-critical  messages  aimed  selectively  at  those  in  the  region  who 
must  act  on  them,  as  well  as  send  the  messages  to  the  appropriate  CPDFs  to  be 
forwarded  to  other  centers,  if  appropriate. 

The  SIS  relay  would  be  within  LOS  range  of  all  terrestrial  nodes  in  a  region. 

Thus,  given  adequate  coverage  and  network  connectivity,  it  would  eliminate  the 
need  for  ground-based  relays  (and,  thus,  the  vulnerability  of  the  soldiers  needed 
to  install,  operate,  and  maintain  such  relays).  It  would  provide  connections  not 
only  between  the  regional  users,  the  sustaining  base,  and  the  CPDFs  but  also 
among  the  users  themselves  (i.e.,  it  would  extend  the  range  of  the  combat  net 
radio),  facilitating  communications  among  mobile  CPs — vertically  and 
horizontally — between  all  command  levels,  regardless  of  their  physical 
separation.  To  provide  multilevel  security,  the  relay  would  use  packet  switching, 
charnel  or  frequency  hopping,  and  encryption. 
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While  our  schematic  (Figure  6.1)  shows  the  relay  and  switch  as  a  single  entity 
located  over  the  region  of  operations,  this  is  not  the  only  possible  configuration. 
The  same  function  could  be  served  by  a  single  satellite  or  a  small  constellation  of 
them,  by  one  or  more  airborne  platforms,  or  by  a  combination  of  space  and 
airborne  platforms.  If  restrictions  prohibit  overflying  a  region,  orbits  might  be 
offshore  or  in  a  neighboring  country.  What  is  necessary  is  that  unobstructed  LOS 
paths  are  provided  for  communications  and  data  exchanges  from  a  variety  of 
physically  separated  and  functionally  diverse  data  sources  to  other  different  sets 
of  physically  separated  and  functionally  diverse  data  users.  For  experimentation, 
exercises,  and  staff  and  operator  training  purposes,  this  could  even  be 
accomplished  by  installing  the  SIS  on  one  or  more  tethered  aerostats  or  on  tall 
towers  (see  Appendix  B). 

Ground  Coverage  as  a  Function  of  Platform  Altitude.  Whether  an  SIS  relay  is 
situated  on  the  ground;  a  mountain;  a  tower;  an  aerial  platform,  such  as  an 
airplane  or  a  tethered  aerostat;  or  in  a  satellite,  the  area  covered  on  the  ground 
from  a  single  point  is  proportional  to  the  platform's  altitude  and  LOS  distance, 
which  is  derived  by  the  following  formula: 

LOS  =  V2RH  , 

where  the  value  for  R  is  4/3  earth  radius  and  H  is  the  altitude  of  the  platform. 

For  example,  at  an  altitude  of  1  km,  the  LOS  extends  about  125  km;  at  6.6  km  it 
extends  322  km;  and  at  13.2  km  it  extends  about  455  km.  Thus,  at  an  altitude  of 
around  13  km,  a  platform  would  probably  cover  an  area  of  operations  for  a 
corps.  It  can  be  seen  from  Figure  6.2  that,  at  an  altitude  of  6.6  km,  a  moderately 
large  island  nation  could  be  entirely  covered  if  the  terrain  permits  LOS.  At  the 
higher  altitude  of  13.2  km,  there  is  some  chance  to  stand-off  the  observation 
platform  from  the  island,  but  only  if  the  island  has  a  favorably  configured 
geometry  (as  indicated  in  the  example  shown  in  Figure  6.2). 

The  number  of  platforms  needed  for  larger  operations  can  be  determined  by  the 
linear  area  to  be  covered  divided  by  the  number  of  relays  at  a  given  altitude 
(Bondanella  et  aL,  1993,  pp.  113-119). 

Space-Based  Relays.  Depending  on  the  location  of  the  CPDFs  relative  to  the 
region  of  operations,  one  or  more  space-based  relays  may  be  required  between 
the  overhead  relay  and  switch  and  each  CPDF.  Space-based  relays  are  not 
necessarily  on  satellite  platforms.  They  may  be  on  a  surrogate  satellite,  such  as 
manned  or  unmanned  fixed-wing  aircraft,  UAVs,  and  tethered  aerostats. 
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Figure  6.2 — Ground  Coverage  of  a  Notional  Island  from  a  Relay  on  an  Aerial  Platform 

at  Altitudes  of  1, 6.6,  and  13.2  km 

Standard  Report  Formats.  The  use  of  standard  formats  for  reports  for  broadcast 
to  recipients  in  the  region  would  have  the  advantage  of  conserving 
communications  capacity  by  minimizing  the  number  of  two-way  data  exchanges. 
In  addition  to  broadcasting  the  data  available,  appropriately  tailored 
standardized  data  structures  would  conserve  relay  capacity  on  satellites  (or  other 
types  of  platforms),  because  only  changed  data  would  need  to  be  sent,  and  the 
same  data  structure  would  be  interoperable  with  multiple  recipients,  greatly 
reducing  duplicative  transmissions.  In  addition,  less  tasking  of  the  CPDFs  for 
updates  would  be  necessary,  because  the  standard  data  structures  would 
automatically  provide  much  of  the  needed  data,  so  the  reports  can  be  tailored  to 
suit  individual  users/  changing  needs. 

Command  and  Control  Vehicles 

The  SIS  architecture  would  minimize  the  complexity  of  communications  and 
data  exchanges  between  computers  in  the  region.  Because  the  CPDF  handles 
problems  of  connection  within  and  between  the  Services  as  well  as  with  the 
Services'  and  allies'  dissimilar  equipment,  less  computer  equipment,  less 
communications  equipment,  and  fewer  operator  personnel  in  the  region  would 
be  necessary.  The  C2Vs  and  the  tactical  operations  centers  would  be  equipped 
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with  computer  workstations,  which,  to  receive  all  desired  reports  sent  from  the 
CPDF,  would  be  tied  to  the  channels  broadcast  from  the  SIS  overhead  relay. 
Based  on  each  commander's  needs  and  the  conflict's  dynamics,  the  operators  at 
these  CPs  and  their  TOCs,  under  the  commander's  direction,  would  redirect  tire 
CPDF's  efforts  through  appropriate  retasking.  The  overhead  relay  would  also 
provide  the  connections  for  this  between  the  commander  and  other  data 
recipients  and  the  CPDF. 

Analysis  at  the  TOCs  would  be  essentially  limited  to  that  using  locally  generated 
data  combined  with  data  provided  by  the  CPDF  and  processed  with  respect  to 
the  local  decision  problem  at  hand.  More  general  types  of  analysis  would  be 
performed  at  the  CPDF  and  at  remote  centers  that  supply  data  to  the  CPDF, 
including  the  sustaining  base.  Tactical  sensor  feeds  would  be  sent  to  the  CPDF. 

The  commanders  and  their  staffs  could  be  equipped  with  two-panel  computer 
notebook  terminals  that  can  be  linked  to  the  overhead  relay  and  switch  either 
directly  or  through  the  CNR.  Two  panels  would  be  more  convenient  than  just 
one,  so  that  receiving  messages  and  preparing  new  ones  using  the  received  data 
could  be  concurrent.  Thus,  commanders  would  receive  standard  reports  from 
the  CPDFs  as  they  choose  wherever  they  may  be.  Each  commander  would  direct 
his  staff  about  new  decisions,  orders,  and  priorities  relative  to  the  operational 
plan.  The  staff,  in  turn,  would  analyze  and  communicate  any  new  collection  and 
production  requirements.  A  staff  representative  in  the  TOC  would  send  those 
tasking  requirements  to  his  supporting  CPDF  through  the  overhead  relay. 


Postulated  SIS  Performance 

When  measured  against  the  informational  and  physical  needs  set  out  earlier,  the 
SIS  concept  appears  to  have  a  number  of  potential  benefits. 

Informational  Needs 

With  regard  to  informational  needs,  the  concept  provides  good  support  for 
operations  in  that  it  would  ensure  that  reports  meet  the  commander's  needs  and 
are  responsive  to  his  tasking.  Also,  the  data  provided  would  be  timely,  accurate, 
and  sufficient.  In  addition,  since  it  is  designed  for  connectivity  with  joint  and 
combined  forces  and  civilian  agencies,  this  concept  would  be  easily 
interoperable.  Production  of  comprehensive  reports  would  be  relatively  easy, 
since  the  architecture  would  use  multiple  distributed  CPDFs  to  provide 
operational  data  across  all  the  functional  domains.  Tasking  would  be  responsive, 
since  the  commander  would  be  directly  linked  to  the  CPDF  network. 
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Physical  Needs 

Since  there  would  be  less  need  for  air-  or  sealift  to  move  equipment  and 
operators  to  a  region,  deployment  would  be  fast;  thus,  the  concept  appears  to 
meet  the  need  for  availability.  The  architecture  would  also  be  self-sustaining, 
since  operations  would  not  depend  on  existing  infrastructure  or  requirements  to 
install  landlines  in  a  region.  Regional  mobility  would  be  handled  through  the 
use  of  overhead  links  for  both  inter-  and  intraregional  data  dissemination  and 
tasking  of  databases  and  collection  sources.  In  addition,  networks,  could  be 
reconfigured  rapidly  to  meet  changes,  so  the  concept  would  be  adaptable. 
Moreover,  the  SIS  concept  meets  the  need  for  reliability  and  robustness  with 
minimum  physical  and  electromagnetic  signatures.  Finally,  it  is  easily 
supportable,  since  only  a  few  different  types  of  equipment  would  be  deployed  to 
the  region. 


Considerations  for  SIS  Concept  Cost  and  Performance 
Trade-Off  Analysis 

The  impacts  on  costs,  force  deployability,  force  mobility,  timeliness  of  reports, 
and  other  factors  discussed  earlier  would  have  to  be  analyzed  to  determine 
whether  the  SIS  concept  could  be  better  implemented  using  either  spacecraft  or 
aircraft,  or  a  combination  of  the  two. 

In  Table  6.1,  to  aid  understanding  of  some  of  the  key  factors  in  a  cost  and 
performance  trade-off  analysis,  we  present  a  matrix  of  possible  factors  related  to 
SIS  performance  and  costs. 

The  table  shows  that  the  location  of  the  SIS  communications  relay  could  be  in 
geosynchronous  orbit,  medium  earth  orbit  (MEO),  low  earth  orbit  (LEO),  or  on 
aircraft  flying  in  the  region.  Also,  the  SIS  could  have  its  message  switching 
system  positioned  at  the  same  location  as  its  communications  relay  system,  or  it 
could  be  located  at  one  or  more  of  the  CPDFs  described  earlier.  In  addition,  the 
SIS  could  have  its  message  storage  system  positioned  at  the  same  location  as  the 
communications  relay  system,  at  one  or  more  CPDFs,  or  this  system  could  be 
located  at  both  CPDFs  and  at  the  communications  relay  system. 


34 


Table  6.1 

Key  Factors  Related  to  SIS  Performance  and  Cost  Trade-Offs 


Message  Switch  Message  Storage  Estimated  Estimated 
SIS  Location  Location  Location  Performance0  Costs0 


Geoynchronous 

With  comm 

At  comm  relay 

orbit 

relay 

AtCPDFs 

AtCPDFs 

At  comm  relay 

AtCPDFs 

and  CPDFs 

Medium  earth 

With  comm 

orbit 

relay 

At  comm  relay 

AtCPDFs 

AtCPDFs 

At  comm  relay 

AtCPDFs 

and  CPDFs 

Low  earth  orbit 

With  comm 

relay 

At  comm  relay 

AtCPDFs 

AtCPDFs 

At  comm  relay 

AtCPDFs 

and  CPDFs 

aFor  future  analysis. 


Considerations  for  SIS  Location  Options 

The  position  of  the  communications  relay  will  determine  the  size  of  the  coverage 
area  of  a  single  SIS  platform  and  system  and  the  time  constraints  associated  with 
this  coverage.  The  coverage  provided  by  a  geosynchronous  satellite  in  view  of 
the  area  of  responsibility  (AOR)  will  be  continuous  and  sufficiently  broad  to 
cover  most  AORs  (except  possibly  at  extreme  southern  or  northern  latitudes). 

One  geosynchronous  satellite  communication  relay  may  provide  sufficient 
message  relay  capacity,  especially  if  all  its  capacity  were  devoted  to  this  mission. 

However,  if  the  SIS  concept  employed  a  LEO  satellite  instead  (e.g.,  one  in  a  100- 
minute  (760  km)  circular  orbit),  the  coverage  provided  would  be  intermittent  and 
brief.  Therefore,  a  number  of  satellites  would  be  needed  to  provide  continuous 
coverage  of  a  relatively  large  AOR  (e.g.,  one  with  an  approximate  areaof  1,000 
km2).  The  number  of  satellites  required  depends  on  orbital  altitude  and  the 
acceptability  of  periodic  interruptions  (predictable)  in  communications.  At  an 
orbital  altitude  of  760  km,  about  60  satellites  would  be  required  for  continuous 
communication.  At  an  orbital  altitude  of  1,250  km,  communication  over  a  1,000- 
km  link  can  be  maintained  about  70  percent  of  the  time  by  a  constellation  of  12 
satellites  with  a  maximum  outage  of  12  minutes.  About  30  satellites  would  be 
required  for  continuous  coverage.  If  the  orbital  altitude  is  raised  to  5,000  km, 
continuous  coverage  over  a  1,000-km  link  can  be  maintained  by  a  constellation  of 
eight  to  nine  satellites. 
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If  the  SIS  switching  function  were  deployed  on  aircraft,  the  instantaneous 
coverage  a  single  aircraft  would  provide  would  be  significantly  less  than  that 
provided  by  a  satellite,  although  for  some  AORs  this  could  be  adequate.  Thus,  a 
large  number  of  aircraft  may  be  needed  to  provide  coverage  for  a  large  AOR, 
especially  if  continuous  24-hour  coverage  is  needed.2  In  addition,  a  relatively 
large  amount  of  airlift  or  sealift  may  be  needed  to  deploy  the  number  of  SIS 
aircraft,  crews,  and  support  equipment  needed  for  operations  in  a  large  AOR. 

On  the  other  hand,  if  a  purely  satellite-based  SIS  concept  were  considered,  it 
would  require  much  less  airlift  to  deploy  in  a  rapid  deployment  operation  (only 
the  SIS  ground  terminals — possibly  in-theater  CPDF  systems — would  have  to  be 
deployed  to  theater,  instead  of  all  the  above  and  the  SIS  aircraft  with  all  their 
support  equipment).  These  lift  concerns  draw  into  question  whether  such  a 
concept  would  satisfy  the  criteria  we  listed  at  the  beginning  of  this  section  and 
point  out  the  need  for  both  detailed  specification  of  the  SIS  concept  and  the 
operational  environment. 

Considerations  for  Message-Switching  System  Options 

With  regard  to  options  of  where  to  put  the  message-switching  system  (either  at 
the  CPDFs  or  on  a  satellite),  it  should  be  noted  that  it  would  be  considerably 
more  expensive  to  put  such  a  system  on  board  a  satellite  than  on  an  aircraft  or  on 
the  ground  or  a  ship.  A  message-switching  system  is  essentially  a  computer 
system  that  can  identify,  sort,  and  route  messages.  Putting  such  a  computer 
system  on  a  satellite  is  complicated  and  entails  significant  additional  cost  relative 
to  a  surface-based  solution,  since  the  computer  chips  must  be  radiation-resistant 
if  placed  in  geosynchronous  orbit  or  MEO.  Until  recently,  this  was  not  even 
possible;  now,  it  is  only  possible  with  low-data-rate  systems. 

Considerations  for  Message-Storage  System  Options 

Similarly,  the  cost  and  design  implications  of  either  putting  a  message-storage 
capability  on  the  satellite  or  at  the  CPDFs  are  not  presented  here.  Message 
storage  on  board  a  satellite  implies  needs  for  on-board  message  processing  and 
for  large  amounts  of  solid-state  memory  or  other  magnetic-media  memory 
devices.  Space  qualification  of  this  additional  hardware  would  be  a  significant 
additional  expense.  Because  of  the  space  and  power  limitations  on  most 
satellites,  the  amount  of  on-board  memory  storage  will  be  limited  relative  to 


2For  example,  the  ratio  between  aircraft  aloft  and  on  the  ground  is  typically  1:5  (as  in  the  case, 
for  example,  of  JSTARS  and  ASARS). 
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what  would  be  available  using  ordinary  computer  servers  located  at  the  ground- 
based  CPDFs.  These  design  trade-offs  need  to  be  included  in  any  analysis  of  SIS 
options.  Alternatively,  the  message-storage  system  could  be  put  at  the  CPDFs. 


Other  Considerations 

The  trade-offs  defined  by  the  three  satellite  system  choices  listed  above  are 
actually  more  complex  than  indicated  when  one  considers  the  fact  that  antenna 
gain  and  satellite  power  requirements  vary  according  to  satellite  altitude  and  the 
ground-terminal  antenna  size  and  power  specified.  Therefore,  the  range  of 
system  costs  and  capabilities  for  the  SIS  concepts  could  vary  enormously. 

These  cost  trade-offs  and  other  implications  of  design  differences  are  mentioned 
here  simply  to  point  to  the  need  to  flesh  out  the  SIS  concept  with  an  appropriate 
level  of  specificity. 
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7.  Common  Picture  of  the  Operation 


As  discussed  in  the  previous  section,  one  important  feature  of  an  effective  C4 
architecture  is  that  it  provide  automatically  disseminated  reports  based  on 
tailored,  standardized  data  structures,  so  that  key  data,  which  is  relevant  to 
formulating  pending  decisions,  would  be  immediately  available  to  the 
commanders  and  their  staffs  in  the  region.  As  we  have  stressed,  commanders 
and  their  staffs,  as  well  as  providers  of  CS  and  CSS,  need  relevant,  timely,  and 
accurate  data  on  the  current  status  of  operations  to  help  them  make  decisions, 
plan  and  execute  operations,  and  analyze  and  assess  results.  They  also  need  the 
results  of  analysis  to  help  them  plan  future  operations  beyond  those  currently 
being  executed. 

We  have  also  stressed  the  need  to  present  data  in  graphical  formats  with 
supplementary  object  identifications  and  explanations,  both  because  (as  previous 
RAND  research  indicates)  commanders  want  such  formats  and  because  the  facts 
about  a  given  situation  are  generally  easier  to  grasp  (by  both  U.S.  forces  and 
allies)  and  apply  from  graphical  formats  than  from  written  communications. 

In  this  section,  we  discuss  how  data  needed  for  a  commander's  awareness  of  his 
situation  might  be  presented  graphically  to  provide  a  CPO.1  More  specifically, 
the  section  first  examines  what  a  CPO  is  and  what  it  does,  how  a  CPO  would  be 
generated  and  disseminated,  how  a  commander's  information  needs  could  be 
defined,  and  some  of  the  benefits  of  a  CPO. 


Defining  a  CPO  and  Its  Purpose 
What  It  Is 

What  is  envisioned  by  the  CPO  is  a  series  of  graphic  images  that  could  be  viewed 
individually  or  in  combination,  much  as  a  series  of  acetate  overlays  are  placed  on 
a  map,  to  produce  a  composite  illustration  of  particular  facts  related  to  a 
particular  area  and  situation.  Basic  images  that  might  be  combined  include  the 
following: 


^Note  that  this  does  not  mean  the  common  picture  will  consist  exclusively  of  images.  The 
graphics  will  often  be  supported  by  icons,  lines,  arrows,  and  other  symbols  and  text,  as  well  as  tables, 
graphs,  and  figures  for  detailed  elaboration  if  the  user  wants  them. 
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*  Topography  of  a  commander's  AOR 

*  Major  terrain  features  (e.g.,  lakes,  rivers,  mountains,  swamps,  desert  areas) 

*  Likely  avenues  of  approach  (e.g.,  roads  and  road  networks,  choke  points, 
defiles,  major  obstacles,  barriers,  mines) 

*  Dispositions  of  friendly  forces 

*  Dispositions  of  neutrals  (e.g.,  civilians,  hostages,  noncombatant  individuals 
and  elements) 

*  Dispositions  of  opposing  forces 

*  Weather  forecasts  and  expected  weather  effects  on  friendly  and  opposing 
force  mobility  and  other  capabilities 

*  Areas  affected  by  storms,  earthquakes,  floods,  fires,  contamination,  etc. 

For  example,  the  background  might  be  a  map  of  preferred  scale,  and  the  details 
and  icons  overlaid  on  it  might  include  relational  objects,  such  as  avenues  of 
approach,  road  networks,  mountains,  and  lakes;  point  objects,  such  as  friendly 
and  hostile  units;  area  objects,  such  as  obstacles  and  obscurants;  and  graphic 
objects,  such  as  sensor  imagery  products,  including  motion  pictures  and  still 
pictures  on  video  clips.  Additional  details  accessible  from  the  CPO  might 
include  tables,  graphs,  photographs,  or  written  text  to  provide  more  detail  about 
such  things  as  personnel  status,  availability  and  locations  of  consumables,  and 
logistic  support.  The  capability  of  magnifying  or  reducing  the  map's  scale  would 
also  be  included  to  enable  commanders  to  focus  on  details  within  a  particular 
area  or  to  view  the  larger  picture. 


What  It  Does 

A  CPO  would  provide  commanders  with  comprehensive  and  timely  views  of  the 
current  operational  situation,  and  of  past,  current,  or  future  operational  plans. 
While  the  same  data  would  be  available  to  all  levels  of  command,  one  important 
feature  would  be  to  allow  users  at  each  command  level  to  easily  access  only  the 
amount  of  detail  desired  (along  the  lines  of  the  data  salad  bar  analogy  referred  to 
in  the  previous  section).  Thus,  the  user  would  be  able  to  select  the  area,  scale, 
and  particular  details  relevant  to  his  needs.  A  commander  would,  for  example, 
be  able  to  access  what  he  wants  to  know  about  friendly  and  opposing  forces  in 
his  particular  area  or  the  entire  region  of  operations,  as  well  as  what  he  wants  to 
know  about  elements  on  his  flanks,  in  the  rear  of  his  position,  or  deep  in  his 
opponent's  rear  area. 
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This  means  that  commanders  need  a  principal  information  agent  with  whom 
they  can  execute  battle  commands  in  the  same  manner  they  interact  with 
maneuver  subordinates  who  serve  as  their  agents  in  their  own  functional 
domains.  Just  as  he  interacts  with  his  other  commander  and  staff  subordinates,  a 
commander  would  give  instructions  to  his  principal  data  manager  and 
information  agent  in  terms  of  the  decisions  he  intends  to  make  and  his 
informational  needs  to  support  them.  His  agent  would  ensure  his  commander's 
intent  is  understood  and  that  the  commander  understands  his  information 
agent's  plan  to  carry  out  the  intent,  down  one  more  echelon  in  that  process. 

Two  terms  can  help  us  understand  the  CPO  concept.  The  first  term  is  the 
common  data  set  (CDS);  the  second  term — the  common  graphical  data  set 
(CGDS),  which  is  the  iconic  representation  of  the  CDS — is  a  subset  of  the  first 
term.  Iconic  representation  fits  ideas  into  a  specified  language  of  limited 
vocabulary.  The  limitation  of  vocabulary  is  what  helps  make  for  commonness, 
but  only  at  coarse  resolution. 

Two  individuals  at  different  echelons  could  look  at  their  own  situation  at 
different  levels  of  resolution  in  terms  of  the  CDS  or  CGDS.  So  long  as  the 
available  data  set  remains  common,  they  could  choose  to  adjust  their  displays  to 
be  the  same.  Their  perceptions  and  understanding  are  necessarily  different,  but 
they  have  a  common  reference  from  which  to  work.  However,  and  necessarily, 
some  local  event  will  occur  that  runs  contrary  to  the  CDS.  At  that  moment,  the 
local  commander's  view  will  instantly  cease  to  be  "common"  until  the  CDS  is 
updated  to  incorporate  this  new  reality.  This  raises  the  question  of  who  will 
update  the  CDS,  and  on  what  basis.  It  also  raises  the  issue  that  the  CDS  is  never 
precisely  accurate — that  it  must  always  be  slightly  out  of  date. 


Generating  and  Disseminating  the  CPO 

The  CPO  would  be  produced  at  a  CPDF  using  data  from  its  own  databases,  those 
of  the  sustaining  base,  and  those  of  other  agencies.  The  standard  and  special 
reports  it  prepares  would  be  primarily  in  the  form  of  imagery,  with  textual, 
tabular,  and  graphical  backup  as  described  above.  Anticipating  the 
informational  needs  of  commanders  and  staffs  in  the  region,  each  CPDF  would 
then  push  relevant  reports  forward  through  the  SIS,  which  would  broadcast  the 
reports,  enabling  the  commanders  and  staffs  in  the  region  to  access  them  as 
desired.  The  images  and  their  textual  and  graphical  backup  would  be  regularly 
updated  by  the  CPDF,  and  the  local  memory  storage  of  the  computer 
workstations  would  be  constantly  updated  by  trickling  updates  to  them  around 
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the  clock.  Constant  automatic  updating  of  local  databases,  by  itself,  is  an 
important  concept. 

Software  at  the  regional  workstations  would  be  used  by  operators  to  manipulate 
the  imagery  received  from  the  CPDF  to  produce  refined  CPOs  pertinent  to  each 
commander's  needs.  Note  that  the  framework  of  the  CPO  is  common  to  all  the 
commands,  but  the  data  are  pertinent  to  each  commander's  decision  or  action 
informational  needs.  Operators  in  the  regional  commands  would  be  needed 
primarily  to  ensure  the  relevance  of  each  CPO  report  according  to  the 
commander's  wishes  and  to  task  the  CPDF  for  additional  reports  or  amplifying 
data,  as  necessary.  Note  also  that  the  subarchitecture  for  the  computer  networks 
would  not  necessarily  follow  the  hierarchical  lines  of  force  organization  but 
would  be  tailored  for  maximum  efficiency  to  support  CtC  connections.  The  very 
fact  that  the  computer  architecture  need  not  mirror  the  command  architecture 
allows  freedom  to  experiment  with  different  architecture  forms  to  optimize  them. 

All  hardware  and  software  would  be  standardized  across  the  region  of 
operations.  In  addition,  the  hardware,  software,  standards,  protocols,  and 
display  formats  would,  to  the  extent  practical,  be  the  same  for  all  situation  report 
categories,  including  those  for  intelligence,  topography,  weather  effects,  CS,  and 
CSS  (e.g.,  engineer,  maneuver  control,  fire  support  and  communications).  This 
standardization  should  reduce  to  an  essential  few  the  unique  skills  and 
operations  to  be  performed  at  the  CPDFs  (e.g„  photo  analysis,  weather  effects  on 
trafficability,  and  intelligence  operations).  Since  the  intelligence  community  has 
already  developed  highly  refined  doctrines,  procedures,  and  facilities  for 
gathering,  producing,  and  disseminating  intelligence,  its  reports  might  be 
considered  as  prototypes  for  other  kinds  of  reports.  However,  it  is  important  to 
avoid  the  rigid  stovepipe  approach  of  any  particular  functional  domain,  because 
such  domains  have  inherent  biases,  specialized  databases,  and  hierarchical  report 
distribution.  The  key  is  to  design  the  architecture  to  support  decisionmakers  first 
and  then  to  ensure  that  the  subarchitectures  of  the  battlefield  operating  systems 
are  compatible,  not  the  other  way  around. 


Defining  Commanders'  Information  Needs 

In  conceptualizing  the  CPO,  we  drew  on  interviews  with  former  commanders 
and  previous  RAND  work  to  determine  what  kinds  of  data  might  be  needed 
(Kahan,  Worley,  and  Stasz,  1989).  This  work  provides  a  foundation  on  which  the 
CPDFs  standard  reports  can  be  based  and  on  which  a  prototype  CPO  could  be 
constructed.  However,  designing  and  optimizing  the  standard  data  format 
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structure  and  reports  for  the  CPO  would  require  testing  and  analyzing 
commanders'  actual  requests  and  usage. 

This  could  be  accomplished  using  prototype  CPOs  and  recording  the  computer 
operations  a  commander  performs  to  modify  them  to  meet  his  needs,  since  the 
patterns  with  which  he  selects  certain  graphical  images  and  amplifying  data  and 
the  amount  of  detail  he  typically  asks  for  will  reflect  his  decisionmaking  patterns. 
Analysts  can  then  use  sensitivity  analysis  to  determine  what  kinds  of  data  are 
most  needed  across  a  range  of  typical  combat  and  noncombat  scenarios  for 
various  kinds  of  decisions  (e.g.,  planning,  attacking,  defending,  and  assisting 
with  disaster  relief).  This  method  of  recording  and  analyzing  commanders'  (or 
staff  members')  computer  operations  ("mouse  tracks")  to  determine  the  kinds  of 
information  they  desire  and  its  information  structures  has  important  implications 
for  all  the  Doctrine,  Training,  Organization,  Leader  Development,  Materiel 
Development  and  Soldiers  elements,  especially  for  doctrine  and  training. 

This  knowledge  can  be  used  to  further  develop  and  optimize  the  CPO  standard 
data  structure  (including  the  types  of  icons,  symbols,  maps,  and  resolution 
ranges),  the  CDS  and  the  CGDS,  as  well  as  the  desired  report  formats  the  CPDFs 
should  be  designed  to  prepare  for  sending  to  regions.  Since  the  types  of  reports 
and  the  amount  of  desired  detail  will  always  depend  on  the  situation  and  will 
vary  with  the  command  level,  type  of  unit,  and  commander,  provisions  could  be 
incorporated  in  a  network's  architecture  to  evaluate  the  process  and  optimize  it. 
These  provisions  would  be  at  the  CPDFs  and  CPs  during  exercises  at  first  and,  if 
practical,  during  actual  operations  in  the  field,  especially  when  the  tempo  of 
conflict  changes.2 

Not  only  is  it  important  to  determine  what  kinds  of  data  commanders  use,  it  is 
also  desirable  to  evaluate  the  usefulness  of  the  information  they  derive  from  it  for 
decisionmaking  and  planning.  Analysts  could  assess  how  useful  particular  kinds 
of  data  are  by,  for  example,  examining  it  with  respect  to  a  set  of  criteria.  One  set 
of  criteria  for  evaluating  the  utility  of  data  to  support  operations  might  be  the 
following: 

•  Relevance  to  the  command  level  and  subordinate  units  (e.g.,  to  the  current 
operational  plan  or  a  future  one) 


2 

^During  actual  operations,  these  data  would  require  protection,  since  they  bear  witness  to  the 
commander's  decision  process. 
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•  Responsiveness  (i.e,,  to  what  degree  the  data  are  suitably  timely  for 
executing  operations  based  on  trials  employing  various  cycle  times  between 
a  commander's  request  for  data  and  when  they  are  actually  provided)^ 

•  Accuracy  (e.g.,  for  planning,  for  attacks  with  weapons,  or  for  assessing 
results  of  weapons  employment) 

•  Adequacy  to  support  the  operation  (e.g.,  sufficiency  and  balance  of  METT-T 
data) 

•  Availability,  which  depends  on  timeliness  (i.e.,  capability  to  obtain 
additional  data,  as  needed,  governed  by  adequate  control  of  the  sources  to 
preclude  either  data  overload  or  unnecessarily  rigid  restrictions  on  the  flow 
of  data). 

In  addition,  analysts  can  determine  what  effects  on  operations  result  from  either 
providing  a  lot  of  certain  kinds  of  data  or,  in  test  cases,  denying  or  limiting  it. 
Thus,  it  should  be  possible  to  measure  the  essential  connection  between  the  data 
provided  and  their  relevance  to  decisionmaking  and  planning,  which,  after  all, 
are  the  best  criteria  for  measuring  the  value  of  information.  Theoretically,  at 
least,  it  should  be  possible  to  relate  gaming  simulations  that  use  an  interactive 
decisionmaking  model — plus  analysis  of  results,  the  relevance,  timeliness, 
accuracy,  adequacy,  and  availability  of  data  to  support  operations — directly  to 
campaigns  and  battles  won  or  lost,  lives  saved,  and  soldiers  at  risk,  including 
those  operating  unprotected  terrestrial  communications  relays. 

Another  way  to  measure  the  data  effectiveness  a  CPDF  using  CPOs  provides 
might  be  to  compare  the  amount  of  time  a  commander  needs  to  make  a  decision 
depending  on  how  (first  separately,  then  in  various  combinations)  relevant, 
timely,  accurate,  and  complete  the  data  received  are.  RAND  has  developed  a 
methodology  for  quantifying  and  measuring  the  temporal  value  of  intelligence 
data  (Cesar  et  al.,  1994). 

Benefits  of  a  CPO 

The  CPO  would  greatly  enhance  interoperability,  since  graphical  displays  can 
transcend  organizational  and  linguistic  barriers.  Specifically,  the  ability  of 
commanders  to  share  data  with  all  the  other  elements  of  their  own  units,  as  well 
as  with  other  units  involved  in  joint  and  combined  operations  (assuming  the 


3For  experimenting  with  data  availability  to  users  according  to  variable  predetermined  time 
cycles,  a  tethered  aerostat  used  as  a  satellite  proxy  platform  at  the  NTC  might  be  designed  to  fade  in 
and  out  in  a  pattern  similar  to  that  of  an  actual  LEO  or  MEO  constellation,  according  to  designated 
times  patterned  after  the  actual  satellites'  access  periodicity. 
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same  data  standards  and  interoperability  profiles  are  used  by  all  the  Services), 
would  facilitate  planning,  maneuvering,  targeting,  battle  damage  assessment, 
and  other  activities.  For  example,  higher-level  commanders  would  be  able  to 
quickly  designate  their  intent  and  objectives,  from  which  would  flow  the 
selection  of  targets  to  attack,  including  the  enemy's  information  sources.  The 
selection  of  targets  would  be  according  to  a  designated  order  and  a  desired 
combination  of  the  air,  land,  and  naval  weapons  of  subordinate  units,  for 
attacking  targets  with  any  combination  of  weapons  of  either  a  single  or  more 
than  one  Service,  either  simultaneously  or  sequentially.  Furthermore,  target  data 
could  be  rapidly,  and  in  some  cases  even  automatically,  sanitized,  declassified, 
and  templated  to  permit  rapid  dissemination  to  allies.  In  addition,  the  objects 
depicted  in  the  CPO  might  also  portray  safe  routes  for  medical  evacuation  or 
supply  movements  for  noncombat  operations,  such  as  disaster  relief,  or  the 
location  of  mines  and  the  capability  of  hostile  forces  to  conduct  combat 
operations. 
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8.  Conclusions  and  Recommendations 


Conclusions 

The  main  conclusion  of  this  concept-formulation  study  is  that  it  is  feasible  for 
joint  task  force  elements  to  operate  while  moving  by  adopting  new  techniques 
for  assessing  information  requirements  and  new  technologies,  architectures, 
procedures,  system s,  and,  particularly,  space-based  systems.  This  requires  major 
revisions  to  the  current  architectures  that  connect  data  sources  with  data  users  in 
a  region  of  operations.  Major  improvements  can  be  achieved  by  designing 
architectures  with  nodes  that  gather,  store,  arrange,  analyze  and  disseminate 
data  according  to  commanders'  informational  needs.  Doing  this  involves,  first, 
defining  and  then  pushing  forward  the  data  that  are  most  often  needed  in  a 
region;  second,  employing  standardized  data  format  structures  for  reports;  and 
third,  providing  each  commander  with  the  means  to  receive  what  he  wants, 
when  he  wants  it,  and  in  the  formats  suited  to  his  particular  style  of 
decisionmaking.  In  addition,  the  efficiency  of  those  architectures  can  be  greatly 
enhanced  by  optimizing  CtC  data  exchanges  separately  from  PtP 
communications. 

Developing  such  architectures  will  require  meeting  at  least  two  challenges,  one 
doctrinal  and  one  technological.  Currently,  there  are  separate  doctrines  for 
intelligence,  fire  support,  CSS,  and  other  functional  domains,  both  within  and 
across  each  of  the  Services,  and  current  processing  is  centered  on  the  source  and 
domain,  rather  than  on  the  decision.  Although  mandated  by  the  Joint  Chiefs  of 
Staff  0CS),  data  integration  is  not  yet  based  on  a  top-down  design  but  on 
combining  designs  for  established  functions  after  each  Service  has  first  met  its 
own  perceived  requirements  independently.  To  achieve  joint  interoperability, 
the  doctrinal  changes  necessary  for  cross-service  and  cross-functional  exchanges 
must  be  focused  on  decisionmakers  and  must  flow  downward  from  a  joint 
operations  perspective  before  interoperability  within  one  Service  and  across  the 
others  is  considered. 

Clearly,  C2  must  dominate  and  set  the  stage  for  all  the  other  functional  domains 
based  on  some  such  perspective,  so  that  all  functions  work  together  as  an 
optimized  whole.  All  the  components  of  the  C2  architecture  will  flow  from  such 
a  perspective:  platforms  and  vehicles,  frequency  bands,  terminal  types  and 
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quantities,  equipment  types,  control  systems,  network  software,  standards,  and 
procedures. 

Many  of  the  technologies  needed  to  support  the  recommended  doctrine  are 
available.  Key  among  these  are  the  new  system  concepts  and  the  development  of 
data  exchange  architectures  that  apply  to  the  technologies  for  displays, 
networking  infrastructure,  processing,  system  and  subsystem  control,  user 
interface,  and  dissemination.  In  particular,  the  use  of  automated  CtC  data 
exchanges  (aided  by  installing  small  transponders  connected  to  on-board  sensors 
in  major  items  of  equipment)  and  the  presentation  of  C2-relevant  data  as 
graphical  imagery  are  now  becoming  available  and  promise  to  enhance 
operational  efficiency  greatly.  However,  these  new  technologies  will  not  mesh 
well  with  the  mixture  of  systems  and  equipment  and  data  system  connection 
architectures  currently  in  use  and  under  development. 

One  reason  for  the  current  variety  of  C4  equipment  and  software  is  that  different 
systems  are  designed  at  different  times,  using  different  technologies.  Attempts 
to  make  systems  technically  compatible  and  interoperable  are  made 
subsequently  through  interface  equipment  buffers  and  software  adaptations,  but 
this  approach  only  adds  more  disjunctures  and  contributes  negatively  to 
seamlessness. 


Recommendations 

Given  these  conclusions,  we  propose  that  the  Army,  in  conjunction  with  the 
other  Services  and  DoD  agencies,  first  redesign  the  C2  structure  to  be  more 
responsive  to  operational  commanders.  The  redesign  should  focus  on  meeting 
the  commanders'  informational  needs  and  do  so  before  examining  the 
architectures  and  their  systems,  equipment,  software,  and  interoperability 
standards  to  support  those  needs.  The  second  task  will  be  to  design  and  evaluate 
a  completely  new  open  architecture  (hardware  and  software)  that  is  top  down  (as 
directed  by  the  JCS  [JCS,  1992])  and  based  primarily  on  C2.  In  addition,  rather 
than  optimizing  communication  systems  and  automation  subarchitectures  for 
each  functional  domain  first  and  then  integrating  them  into  a  meta-architecture 
for  C2,  all  the  other  functional  domains  (e.g.,  intelligence,  maneuver,  CSS,  fire 
support,  air  defense,  aviation)  should  be  an  integral  part  of  the  architecture  by 
design,  beginning  at  the  most  fundamental  data-element  level. 

As  mentioned  above,  attempts  to  make  systems  technically  compatible  and 
interoperable  are  now  being  made  through  interface  equipment  buffers  and 
software  adaptations,  which  contributes  negatively  to  seamlessness.  Therefore, 
we  recommend  that  a  coherent  architecture  and  standards  for  systems  (now 
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being  directed  by  the  Defense  Information  Systems  Agency)  for  interoperability 
be  based  top  down  from  a  joint  operations  perspective  and  that  it  be 
implemented  over  a  period  of  several  years  in  an  evolutionary  and  programmed 
manner  while  obsolescent  and  noncontributing  architectures,  standards,  and 
systems  are  disposed  of  aggressively.^  The  Digitization  Master  Plan  being 
prepared  by  ADO  should  make  joint  interoperability  paramount,  including  the 
doctrinal  changes  necessary  for  cross-service  and  cross-functional  exchanges  to 
support  the  joint  operations  perspective. 

To  develop  such  a  coherent  architecture,  we  recommend  that  the  Army  start  by 
describing  its  operational  objectives,  preferably  in  combination  with  the  other 
Services.  This  will  require  reexamining  the  data  requirements  of  commanders 
for  performing  C2  and  decisionmaking  and  defining  the  anticipated  movement 
dynamics  of  the  forces  in  future  operational  settings. 

It  is  important  to  emphasize  the  importance  of  defining  informational  needs  first, 
before  examining  the  physical  needs  of  architectures,  their  systems'  equipment, 
and  software.  The  requirements  for  exchanging  data  and  other  informational 
reports  must  be  fully  analyzed  before  a  C2V  can  be  designed  and  its  terminal 
systems  identified  or  any  subarchitecture  can  be  adequately  described.  And 
because  requirements  are  continually  changing,  the  process  for  defining  them 
must  also  be  dynamic.  The  Army  will  need  to  specify  the  required  data  by  type 
for  both  communications  and  data  exchanges,  identify  the  providers  and 
intended  recipients  (both  human  and  computer)  of  databases  and  reports 
necessary  for  C2,  and  define  the  data  structure  and  desired  reports  with  regard  to 
format,  content,  volume,  and  timeliness.  This  approach  runs  contrary  to  the 
Army's  past  approach;  because  of  this,  the  systems  the  Army  inherited  and  must 
now  use  make  it  difficult  for  the  Army  to  follow  the  new  JCS  guidance  0CS, 
1992).2 

Defining  C2  subarchitectures  by  putting  information  before  equipment  requires 
addressing  who  makes  what  kinds  of  decisions  at  what  levels  and  who  must 
make  decisions  locaEy.  Again,  this  approach  is  quite  different  from  the 


fin  analyzing  the  potential  utility  of  all  systems  currently  in  use  and  under  development,  the 
Army  should  take  the  following  approach  to  determine  their  suitability.  If  an  item  does  not 
contribute  substantially  or  if  it  contains  obsolete  equipment  and  software  whose  wearout  period 
cannot  be  justified,  new  production  should  be  quickly  terminated  and  current  equipment  should  be 
discarded  as  soon  as  possible  while  continuing  to  work  to  acquire  the  new  objective  architecture. 

2Recently,  Secretary  of  Defense  William  Perry  directed  the  Services  to  define  their  legacy  and 
objective  C2  systems;  however,  until  the  Army  develops  a  comprehensive  objective  architecture  for 
the  future,  it  will  be  exceedingly  difficult  to  identity  which  systems  to  discard  and  which  to  retain 
and  upgrade.  As  a  first  step,  then,  an  improved  methodology  for  making  trade-off  analyses  and  a 
procedure  for  identifying  and  acquiring  information  technology  in  discrete  steps  are  considered 
essential.  (As  an  input  to  this  process.  Appendix  A  describes  a  concept  for  acquiring  new  technology 
in  time-discrete  steps.) 
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traditional  one  the  Army  uses,  which  involves  periodically  attempting  to  define 
all  the  communications  requirements  at  a  given  time  based  on  "who  needs  to  talk 
to  whom,  how  much  and  how  often."  Such  an  approach  is  typically  inflated  to 
cover  all  possible  situations  and  can  never  be  completed,  because  the 
environment  and  the  Army  are  dynamic,  and  because  the  possible  situations 
and,  especially,  the  supporting  technologies  keep  changing.  This  only  further 
emphasizes  the  importance  of  focusing  on  decisionmaking  as  the  principal 
objective  and  on  defining  the  products  needed  for  that  before  addressing  the 
architectures  and  component  systems. 

The  next  step  will  be  to  develop  a  set  of  criteria  that  an  architecture  must  satisfy 
to  meet  the  desired  informational  and  physical  objectives.  Then,  architectures 
will  need  to  be  designed  and  evaluated  against  both  criteria  and  objectives. 

The  architectures  will  need  to  be  tested  and  improved.  We  recommend  using  the 
ADO  as  the  office  to  conduct  experiments  as  part  of  the  Army's  campaign  plan 
for  Force  XXI.  Experiments  could  be  done  in  coordination  with  the  Battle 
Laboratories  to  obtain,  for  example,  clearer  definitions  of  the  SIS,  CPO,  CDS, 
CGDS,  and  the  CPDF.  The  design  of  and  responsibilities  for  maintaining 
databases  and  the  content  of  CtC  data  exchanges  (both  forward  and  rearward), 

CS  and  CSS  data  aggregation,  and  reporting  of  CSS  consumption  rates  should 
also  evolve.  Also,  the  automatic  reporting  of  CS  and  CSS  data  through  the  new 
C4  architecture  from  units  in  the  region  through  the  overhead  relay,  to  the 
CPDFs,  and  finally  to  the  sustaining  base  should  be  developed,  tested,  and 
evaluated.  In  addition,  the  development  and  improvement  of  prototype  CPOs, 
including  the  CDS  and  CGDS  referred  to  earlier,  should  be  tested  to  better 
understand  the  kinds  of  data  commanders  and  their  staffs  require  for 
decisionmaking  and  planning  for  both  combat  and  noncombat  operations  and 
how  reports  can  be  structured  and  tailored  to  the  particular  preference  patterns 
of  commanders  for  decisionmaking,  command  and  control,  and  planning  future 
operations. 

Finally,  we  recommend  that  the  Army  look  for  potential  sources  of  resources 
from  industry  and  elsewhere  by  conceptualizing  and  describing  new 
applications  for  information-related  technologies  that  also  have  potential  military 
uses.  The  following  are  three  example  categories: 

1.  Mobile  crisis  control  action  centers  for  use  by  the  National  Guard,  Federal 
Emergency  Management  Agency,  the  U.S.  Department  of  Forestry,  states, 
and  large  cities 

2.  Small,  low-cost  transponders  connected  to  space-based  data  terminals 
installed  in  major  items  of  equipment,  along  with  on-board  sensors,  to 


48 


monitor  automatically  and  to  report  periodically  on  status,  location,  on¬ 
board  activities,  and  consumption  rates  (e.g.,  for  a  number  of  military 
applications,  the  operational  condition  of  vehicles  and  weapons  and  the 
status  of  POL,  munitions,  and  spare  parts) 

3.  Highly  mobile  C2Vs  connected  to  an  overhead  relay  and  switch  for  television 
and  other  news  media  reporting,  environmental  survey  and  oil  exploration 
teams,  etc.,  in  regions  that  have  limited  or  no  available  communications 
infrastructure. 
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Appendix 

A.  Concept  for  Acquiring  New  Information 
Technologies  in  Discrete  Steps 


Finding  ways  to  select,  develop  or  adapt,  and  integrate  new  equipment, 
software,  and  procedures  into  the  current  C4  architecture  presents  challenges, 
primarily  because  new  data-collection,  transfer,  manipulation,  and  dissemination 
technologies  are  proceeding  at  a  much  faster  pace  than  the  Army  or  the  other 
Services  are  presently  capable  of  acquiring  or  assimilating.  This  fact,  exacerbated 
by  declining  budgets  for  acquiring  new  equipment,  could  mean  that  adding  new 
capabilities  for  improving  C4  may  be  continually  stretched  out  over  a  longer 
period.  This  appendix  describes  a  concept  for  acquiring  new  information 
technologies  in  discrete  steps. 

The  General  Pace  of  Advances 

Figure  A.l  illustrates  in  a  general  way  the  pace  of  advances  in  relevant 
communications  and  automation  technologies  compared  with  the  Services' 
ability  to  acquire  and  apply  them  in  the  future.  As  budgets  become  flatter  and 
even  turn  downward,  the  gap  between  what  technology  can  provide  and  what 
the  Army  can  acquire  will  theoretically  widen  if  a  traditional  sequential 
acquisition  process  is  used. 


Planning  by  Epochs 

One  way  to  address  this  difficulty  might  be  to  plan  according  to  epochs — that  is, 
points  in  time  characterized  by  distinctive  new  ways  of  acquiring  technologies 
for  C4 — and  to  design  the  systems  in  each  epoch  with  the  same  generation  of 
technology.1  Thus,  equipment,  software,  and  operating  procedure  compatibility 
could  be  more  readily  achieved,  instead  of  grafting  new  systems  onto  obsolescent 
architectures  by  patchwork,  with  the  assumption  that  the  epoch  approach  is  both 
operationally  desirable  and  cost-effective. 


1Epoch  technology-acquisition  models  might  be  developed  for  systems  of  the  other  functional 
domains  as  well. 
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Advances  in 
communications 
and  automation 
technologies 


Public/domestic 


Figure  A.l — Postulated  Acquisition  Gap  Between  Technology  and 
Capabilities,  Linear  Acquisition  Model 


According  to  this  concept,  at  any  given  time,  there  might  be  three  epochs:  the 
current  step,  an  evolving  one,  and  a  future  design.  Each  epoch  would  be 
characterized  by  significant  changes  in  the  major  C4  elements  (e.g.,  data 
processing  requirements,  network  configurations,  interface  standards  and 
protocols,  and  operating  systems  and  their  platforms).  Within  each  epoch,  the 
major  systems  and  their  components  would  either  be  the  same  or  very  similar  to 
all  the  others  in  the  same  epoch;  at  least,  they  would  be  of  the  same  technology 
generation  and,  therefore,  should  be  highly  compatible.  Figure  A.2  illustrates 
this  concept  notionally. 


Advances  in 
communications 
and  automation 
technologies 


Public/domestic 


Figure  A.2 — Postulated  Gap  Between  Technology  and  Capabilities 
Acquisition,  Epoch  Acquisition  Model 
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B.  Concept  for  Space-Based  Platform 
Proxies  for  Battalion-Level  Training  at 
the  National  Training  Center 


This  appendix  briefly  sketches  a  concept  for  creating  a  realistic  environment  for 
training  by  simulating  a  range  of  space-based  platform  options  so  units  can 
interact  with  them  through  various  space-based  terrestrial  components.  Some  of 
the  objectives  are  to 

•  help  warfighters  train  as  they  would  fight 

•  give  tactical  units  actual  space-support  terminals 

•  train  regularly  with  space-based  platform  proxies  (e.g.,  tethered  aerostats, 
UAVs) 

•  experience  ground  coverage  of  space-based  capabilities 

•  provide  "hands-on"  experience  with  actual  equipment 

•  enable  doctrine  to  be  used  realistically 

•  expose  Army  tactical  decisionmakers  to  current  doctrine  for  space 
exploitation,  to  interactions  with  space  capability  providers,  and  to  other 
space  mission-area  organizations 

•  expose  Army  tactical  leaders  to  materiel  acquisition,  software,  standards  for 
interoperability,  protocols,  and  other  key  issues 

•  provide  examples  of  the  kinds  of  space-related  training  experience 
envisioned  by  the  Army's  leadership 

•  provide  hands-on  training  with  satellites  at  reduced  costs 

•  provide  operational  and  other  data  for  performing  cost  trade-offs  between 
space  proxies  and  commercially  leased  communications  satellites. 

The  area  size  of  the  operational  environment  where  training  is  held  at  the  NTC  is 
represented  by  a  central  corridor  that  is  roughly  15  by  30  km.  This  area  is 
surrounded  by  mountainous  terrain  and  is  cut  by  a  set  of  relatively  low-lying 
mountains  containing  three  main  passes:  Debnam,  Brown,  and  Goat  Trail.  This 
area  on  the  ground  can  be  covered  by  a  single  aerostat  operating  at  an  altitude  of 
about  200  ft,  but  there  is  a  region  of  several  km  that  is  denied  line-of-sight 
observation  because  of  the  low-lying  mountains  (perhaps  around  1,000  ft  high). 
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The  situation  is  indicated  in  Figure  B.l.  A  sensor  platform  at  height  H  km  is 
located  at  the  end  of  the  15  x  30  km  range  and  is  R  km  from  mountains  M  m 
high.  An  area  X  km  long  behind  the  mountains  is  obscured  and  is  calculated  by 
solving  for  X  assuming  a  flat  earth: 

H  R  +  X  _ 

M  X  ; 


If  M  =  1  km  and  R  =  10  km,  then  solve  for  X  with  H  varying  from  1.33  to  30  km 
above  ground  level. 

The  percentage  of  coverage  of  the  30-km  long  area  observed  by  a  sensor  at  height 
H  then  is 


Percentage  coverage  achieved  = 


1-X 

30 


•  100  . 


Table  B.l  shows  the  increase  in  percentage  of  the  central  corridor  that  is  covered 
as  the  height  of  the  sensor  platform  (H)  is  increased.  Shown  also  is  the  associated 
decrease  in  the  obscured  region  (X).  These  results  are  graphed  in  Figure  B.2. 
Note  the  significant  increase  in  coverage  as  the  platform  altitude  is  raised  from 
1.3  to  5  km.  Although  almost  all  the  region  beyond  the  mountain  is  obscured 
when  the  sensor  platform  is  at  1.34  km,  over  90  percent  is  covered  with  platform 
heights  above  5  km  and  almost  all  when  above  20  km.1 


The  LOS  is  not  significantly  different  at  these  higher  altitudes  than  it  would  be 
for  a  space-based  sensor.  Thus,  a  tethered  aerostat  could  be  substituted  for  a 


1For  lower  mountain  ranges,  say  0.5  km,  the  high-percentage  coverage  values  are  obtained  with 
sensor  platforms  at  even  lower  altitudes. 
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Platform 


Figure  B.l — Obscuration  of  the  Lower  Region  of  the  Central  Corridor 


satellite  during  training  excercises  at  NT C  while  providing  similar  coverage  and 
connectivity  capabilities  using  the  same  ground  terminals,  but  at  a  much  lower 
cost 

Some  of  the  issues  would  be  the  obstacle  an  aerostat  and  its  tether  would  present 
to  helicopters  and  low-flying  aircraft  and  the  cost  of  providing  and  operating 
such  a  satellite  surrogate. 


Table  B.l 

Coverage  of  the  NTC  Central  Corridor  as  a 
Function  of  Sensor  Altitude 


Obscured  Coverage  of 
Sensor  Height  Region  Central 

(km)  (km)  Corridor  (%) 


1.34 

2.50 

5.00 

10.00 

20.00 

30.00 


29.40 

6.70 

2.50 

1.10 

0.50 

0.30 


1.96 

77.80 

91.70 

96.30 

98.30 
98.90 


NOTE:  Assumes  the  sensor  platform  is  10  km  behind 
a  1-km-high  mountain  range. 
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